Remove chapter statuses and "Introduction" headings

Closes #971
hadley · Mar 29, 2023 · 6fb87d5 · 6fb87d5
1 parent 81f1c9a
commit 6fb87d5
Show file tree

Hide file tree

Showing 21 changed files with 2 additions and 56 deletions.
diff --git a/R-CMD-check.Rmd b/R-CMD-check.Rmd
@@ -2,11 +2,8 @@
 
 ```{r, echo = FALSE}
 source("common.R")
-status("polishing") 
 ```
 
-## Introduction
-
 `R CMD check` is composed of over 50 individual checks, described in the following sections.
 For each check, we briefly describe what it does, what the most common problems are, and how to fix them.
 When you have a problem with `R CMD check` and can't understand how to fix it, use this list to help figure out what you need to do.

diff --git a/code.Rmd b/code.Rmd
@@ -4,8 +4,6 @@
 source("common.R")
 ```
 
-## Introduction
-
 The first principle of making a package is that all R code goes in the `R/` directory.
 In this chapter, you'll learn about organising your functions into files, maintaining a consistent style, and recognizing the stricter requirements for functions in a package (versus in a script).
 We'll also remind you of the fundamental workflows for test-driving and formally checking an in-development package: `load_all()`, `test()`, and `check()`.

diff --git a/data.Rmd b/data.Rmd
@@ -2,11 +2,8 @@
 
 ```{r, echo = FALSE}
 source("common.R")
-status("polishing")
 ```
 
-## Introduction
-
 It's often useful to include data in a package.
 If the primary purpose of a package is to distribute useful functions, example datasets make it easier to write excellent documentation.
 These datasets can be hand-crafted to provide compelling use cases for the functions in the package.

diff --git a/dependencies-in-practice.Rmd b/dependencies-in-practice.Rmd
@@ -2,11 +2,8 @@
 
 ```{r, echo = FALSE}
 source("common.R")
-status("polishing")
 ```
 
-## Introduction
-
 This chapter presents the practical details of working with your dependencies inside your package.
 If you need a refresher on any of the background:
 

diff --git a/dependencies-mindset-background.Rmd b/dependencies-mindset-background.Rmd
@@ -2,11 +2,8 @@
 
 ```{r, echo = FALSE}
 source("common.R")
-status("polishing")
 ```
 
-## Introduction
-
 You take a dependency when your package uses functionality from another package (or other external tool).
 In @sec-description-imports-suggests, we explained how to declare a dependency on another package by listing it in `DESCRIPTION`, usually in `Imports` or `Suggests`.
 But that still leaves many issues for you to think about:

diff --git a/description.Rmd b/description.Rmd
@@ -2,11 +2,8 @@
 
 ```{r, echo = FALSE}
 source("common.R")
-status("polishing")
 ```
 
-## Introduction
-
 `DESCRIPTION` and `NAMESPACE` are two important files that provide metadata about your package.
 The `DESCRIPTION` file provides overall metadata about the package, such as the package name and which other packages it depends on.
 The `NAMESPACE` file specifies which functions your package makes available for others to use and, optionally, imports functions from other packages.

diff --git a/license.Rmd b/license.Rmd
@@ -4,8 +4,6 @@
 source("common.R")
 ```
 
-## Introduction
-
 The goal of this chapter is to give you the basic tools to manage licensing for your R package.
 Obviously, we are R developers and not lawyers, and none of this is legal advice.
 But fortunately, if you're writing either an open-source package or a package used only within your organisation[^license-1], you don't need to be an expert to do the right thing.

diff --git a/lifecycle.Rmd b/lifecycle.Rmd
@@ -2,11 +2,8 @@
 
 ```{r, echo = FALSE}
 source("common.R")
-status("polishing")
 ```
 
-## Introduction
-
 This chapter is about managing the evolution of your package.
 The trickiest part of managing change is balancing the interests of various stakeholders:
 

diff --git a/man.Rmd b/man.Rmd
@@ -2,11 +2,8 @@
 
 ```{r, echo = FALSE}
 source("common.R")
-status("polishing")
 ```
 
-## Introduction
-
 In this chapter, you'll learn about function documentation, which users access with `?somefunction` or `help("somefunction")`.
 Base R provides a standard way of documenting a package where each function is documented in a **topic,** an `.Rd` file ("R documentation") in the `man/` directory.
 `.Rd` files use a custom syntax, loosely based on LaTeX, and can be rendered to HTML, plain text, or pdf, as needed, for viewing in different contexts.

diff --git a/misc.Rmd b/misc.Rmd
@@ -2,11 +2,8 @@
 
 ```{r, echo = FALSE}
 source("common.R")
-status("polishing")
 ```
 
-## Introduction
-
 The first two chapters in this part of the book cover the two most obvious things that people distribute via an R package: functions (@sec-r) and data (@sec-data).
 But that's not all it takes to make an R package.
 There are other package components that are either required, such as a `DESCRIPTION` file, or highly recommended, such as tests and documentation.

diff --git a/other-markdown.Rmd b/other-markdown.Rmd
@@ -2,11 +2,8 @@
 
 ```{r, echo = FALSE}
 source("common.R")
-status("polishing")
 ```
 
-## Introduction
-
 In this chapter we highlight two files that are conventionally used to provide some package-level documentation.
 These two are important, because they are featured on both the CRAN landing page and the pkgdown site for a package:
 

diff --git a/package-within.Rmd b/package-within.Rmd
@@ -16,8 +16,6 @@ Unused ideas for little data cleaning tasks:
 * using the degree symbol properly with unicode escape sequence
 -->
 ```
-## Introduction
-
 This part of the book ends the same way it started, with the development of a small toy package.
 @sec-whole-game established the basic mechanics, workflow, and tooling of package development, but said practically nothing about the R code inside the package.
 This chapter focuses primarily on the package's R code and how it differs from R code in a script.

diff --git a/preface.Rmd b/preface.Rmd
@@ -2,7 +2,6 @@
 
 ```{r, echo = FALSE}
 source("common.R")
-status("restructuring")
 ```
 
 Welcome to the 2nd edition of R Packages!

diff --git a/release.Rmd b/release.Rmd
@@ -2,11 +2,8 @@
 
 ```{r, echo = FALSE}
 source("common.R")
-status("polishing")
 ```
 
-## Introduction
-
 We've been calling out CRAN-specific concerns throughout the book, on our journey through the various parts of a package, such as tests and examples.
 In this chapter, we focus on the actual process of releasing a package to CRAN, for the first time or as an update.
 

diff --git a/software-development-practices.Rmd b/software-development-practices.Rmd
@@ -2,11 +2,8 @@
 
 ```{r, echo = FALSE}
 source("common.R")
-status("polishing")
 ```
 
-## Introduction
-
 In this last part of the book, we zoom back out to consider development practices that can make you more productive and raise the quality of your work.
 Here we'll discuss the use of version control and continuous integration.
 In @sec-lifecycle we discuss how the nature of package maintenance varies over the lifecycle of a package.

diff --git a/structure.Rmd b/structure.Rmd
@@ -4,8 +4,6 @@
 source("common.R")
 ```
 
-## Introduction
-
 This chapter will start you on the road to package development by converting the implicit knowledge you've gained from *using* R packages into the explicit knowledge needed to *create and modify* them.
 You'll learn about the various states a package can be in and the difference between a package and library (and why you should care).
 

diff --git a/testing-basics.Rmd b/testing-basics.Rmd
@@ -4,10 +4,8 @@
 source("common.R")
 ```
 
-## Introduction
-
-Testing is a vital part of package development: it ensures that your code does what you want. 
-Testing, however, adds an additional step to your workflow. 
+Testing is a vital part of package development: it ensures that your code does what you want.
+Testing, however, adds an additional step to your workflow.
 To make this task easier and more effective this chapter will show you how to do formal automated testing using the testthat package.
 
 The first stage of your testing journey is to become convinced that testing has enough benefits to justify the work.

diff --git a/vignettes.Rmd b/vignettes.Rmd
@@ -2,11 +2,8 @@
 
 ```{r, echo = FALSE}
 source("common.R")
-status("polishing")
 ```
 
-## Introduction
-
 A vignette is a long-form guide to your package.
 Function documentation is great if you know the name of the function you need, but it's useless otherwise.
 In contrast, a vignette can be framed around a target problem that your package is designed to solve.

diff --git a/website.Rmd b/website.Rmd
@@ -2,11 +2,8 @@
 
 ```{r, echo = FALSE}
 source("common.R")
-status("polishing")
 ```
 
-## Introduction
-
 At this point, we've discussed many ways to document your package:
 
 -   Function documentation or, more generally, help topics (@sec-man).

diff --git a/whole-game.Rmd b/whole-game.Rmd
@@ -33,8 +33,6 @@ debug <- FALSE
 where <- "tmp_session"
 ```
 
-## Introduction
-
 *Spoiler alert!*
 
 This chapter runs through the development of a small toy package.

diff --git a/workflow101.Rmd b/workflow101.Rmd
@@ -4,8 +4,6 @@
 source("common.R")
 ```
 
-## Introduction
-
 Having peeked under the hood of R packages and libraries in @sec-package-structure-state, here we provide the basic workflows for creating a package and moving it through the different states that come up during development.
 
 ## Create a package {#sec-workflow101-create-package}