Fix lots of small typos and make limited improvements to the grammar

bot_cheatsheet.Rmd

@@ -90,15 +90,15 @@ See [editorial policy](#policiesreviewprocess).
 
 ### Check package with pkgcheck {#check-package-with-pkgcheck}
 
-Generally only on pre-submission inquiries, or when authors otherwise indicate that package has substantially changed.
+Generally only on pre-submission inquiries, or when authors otherwise indicate that the package has substantially changed.
 
 ```markdown
 @ropensci-review-bot check package
 ```
 
 ### Check statistical standards {#check-statistical-standards}
 
-Generally only on pre-submission inquiries, or when authors otherwise indicate that package has substantially changed.
+Generally only on pre-submission inquiries, or when authors otherwise indicate that the package has substantially changed.
 
 ```markdown
 @ropensci-review-bot check srr

maintenance_changing_maintainers.Rmd

@@ -43,7 +43,7 @@ We have a call for contributors section in our newsletter that comes out every t
   For general help on changing code in a package, see the [Package evolution](#evolution)
   section.
 
-  When thinking though this, there are many considerations.
+  When thinking through this, there are many considerations.
 
   How much time do you have to spend on the package? If you have very limited time, it'd be best to focus on the most critical tasks, whatever those are for the package in question. If you have ample amount of time, your goals can be larger in scope.
 

maintenance_cheatsheet.Rmd

@@ -8,7 +8,7 @@ A reminder of infrastructure and contact channels for maintainers of rOpenSci pa
 ## Help needed? {#help-needed}
 
 If you need punctual help (say, a PR review; or some CI troubleshooting), or help looking for co-maintainers or a new maintainer, or if you need us to retire your package, ping us in GitHub via `@ropensci/admin` or email `info@ropensci.org`.
-You can also use our slack package maintenance channel.
+You can also use our Slack package maintenance channel.
 
 Never hesitate to ask for help.
 
@@ -20,17 +20,17 @@ please contact us via `info@ropensci.org`.
 
 ## Other GitHub topics {#other-git-hub-topics}
 
-If you have any GitHub question or request (adding a collaborator to the GitHub organization for instance) you can use a public channel of the rOpenSci slack workspace or ping `@ropensci/admin` on GitHub.
+If you have any GitHub questions or requests (adding a collaborator to the GitHub organization for instance) you can use a public channel of the rOpenSci Slack workspace or ping `@ropensci/admin` on GitHub.
 
 ## pkgdown documentation {#pkgdown-documentation}
 
 See [rOpenSci docs](#rodocsci).
 
 ## Access to rOpenSci slack workspace {#access-to-ropensci-slack-workspace}
 
-Package maintainers and developers should get access to [rOpenSci slack](https://contributing.ropensci.org/resources.html#channels).
+Package maintainers and developers should get access to [rOpenSci Slack](https://contributing.ropensci.org/resources.html#channels).
 If you did not get the invitation or did not accept it in time,
-or if you want a new regular contributor receive an invitation please email `info@ropensci.org`,
+or if you want a new regular contributor to receive an invitation please email `info@ropensci.org`,
 indicating to which email address you wish to receive the invitation.
 
 You might find the #package-maintenance channel relevant for Q\&A as well as friendly commiseration when needed.

maintenance_contributing.Rmd

@@ -19,7 +19,7 @@ We welcome code and non-code contributions from new and seasoned coders at any c
 
 What are some benefits of contributing?
 
-- Connect with a community  who shares your interest in making science more open
+- Connect with a community that shares your interest in making science more open
 - Learn from people outside your domain who use R with challenges similar to yours
 - Ask and answer new research questions by getting to know new software tools and allies
 - Feel confident and supported in your efforts to write code and develop software

maintenance_curation.Rmd

@@ -11,9 +11,9 @@ ongoing maintenance of packages developed as part of rOpenSci activities
 and/or under the rOpenSci GitHub organization. This curation policy aims
 to support these goals:
 
--   Ensure packages provided by rOpenSci are up-to-date and high quality
+-   Ensure packages provided by rOpenSci are up-to-date and of high quality
 
--   Provide clarity as to the development status and and review status
+-   Provide clarity as to the development status and review status
     of any software in rOpenSci repositories
 
 -   Manage maintenance effort for rOpenSci staff, package authors, and
@@ -24,8 +24,8 @@ to support these goals:
 
 ```
 
-Elements of infrastructure described
-below needed for implementation of the policy are in some cases partly
+The elements of infrastructure described
+below needed for the implementation of the policy are in some cases partly
 built and in other cases not yet begun. We aim to adopt this policy in
 part to prioritize work on these components.
 
@@ -47,7 +47,7 @@ as part of rOpenSci projects. These packages may also be peer-reviewed
 packages, but are not necessarily peer reviewed. Many are infrastructure
 packages that fall out of scope for peer review.
 
-- Staff-maintained packages will be listed in the registry with tag
+- Staff-maintained packages will be listed in the registry with the tag
   "staff\_maintained" and listed on rOpenSci's packages web page or similar
   venues with tag "staff-maintained"
 
@@ -68,8 +68,8 @@ packages that fall out of scope for peer review.
 - Packages consistently failing and without an ongoing plan to return
   to active maintenance will move to "archive" status. When
   archived, staff packages will move to the "ropensci-archive"
-  repository (to be created) and and gain the "archived" type in
-  the registry. They will not be built on rOpenSci system.
+  repository (to be created) and gain the "archived" type in
+  the registry. They will not be built on the rOpenSci system.
 
 - Archived packages will not be displayed by default on the packages
   web page. A special tab of packages pages will display
@@ -79,7 +79,7 @@ packages that fall out of scope for peer review.
 - Archived packages can be unarchived when the old or a new maintainer
   is willing to address the problems and wants to revive the
   package. For that please [contact rOpenSci](https://ropensci.org/contact/).
-  They are transferred to the ropenscilabs organization.
+  They are transferred to the rOpenSci Labs organization.
 
 ## Peer-reviewed packages {#peer-reviewed-packages}
 
@@ -89,20 +89,20 @@ community and have passed through peer review. They need to be
 at the time of submission to be reviewed.
 
 - Upon acceptance, these peer-reviewed packages are transferred from
-  the author's GitHub to the "ropensci" GitHub organization 
+  the author's GitHub to the rOpenSci GitHub organization 
   or alternatively tracked by adding them to a [JSON file](https://github.com/ropensci/roregistry/blob/gh-pages/info/not_transferred.json).
 
 - Peer-reviewed packages will be in the registry tagged as
   "peer-reviewed" and have a peer-reviewed badge in their README.
 
 - Peer-reviewed packages will be listed on rOpenSci's web page or
-  similar venues with tag "peer-reviewed"
+  similar venues with the tag "peer-reviewed"
 
 - Peer-reviewed packages and their docs will be built by rOpenSci
   [system](https://status.ropensci.org/). This system does not send notifications
   but it outputs results as GitHub commit status (red check mark or red cross).
 
-- Annually or bi-annually, rOpenSci staff will review packages in a
+- Annually or biannually, rOpenSci staff will review packages in a
   failing state or have been failing for extended periods, and
   contact the authors to determine ongoing maintenance status and
   expected updates. Based on this exchange, rOpenSci may opt to
@@ -169,22 +169,22 @@ at unconferences
 - Incubator packages and their docs will be built by rOpenSci
   [system](https://status.ropensci.org/). This system does not send notifications
   but it outputs results as GitHub commit status (red check mark or red cross).
-  The docs will indicate clearly the package is experimental.
+  The docs will indicate clearly that the package is experimental.
 
 - Biannually or annually, rOpenSci will contact incubator maintainers
   about repositories at least three months old, inquiring about
   development status and author preferences for migration to
-  peer-review, ropensci-archive, or to author organizations. Based
-  on response, package will be migrated immediately, peer review
+  peer-review, rOpenSci-archive, or to author organizations. Based
+  on the response, the package will be migrated immediately, peer review
   will be initiated, or migration will be deferred to the next
-  review. Incubator packages will be migrated to ropensci-archive by
+  review. Incubator packages will be migrated to the ROpenSci-archive by
   default after one year, following [transfer guidance](#archivalguidance).
 
 - Archived incubator packages will gain the "archived" type.
 
 ### Incubator non-R-packages {#incubator-non-r-packages}
 
-- The "incubator" organization will also include non-R-package
+- The "incubator" organization will also include non-R package
   projects.
 
 - These projects will not be listed in the registry or appear on a web
@@ -205,7 +205,7 @@ rOpenSci staff and community members.
 
 - Books will be hosted at books.ropensci.org
 
-- Books may be mature or in-development, but must have minimal
+- Books may be mature or in development, but must have minimal
   outlines/content before migrating into "ropensci-books" (e.g.
   from "ropenscilabs").
 

maintenance_evolution.Rmd

@@ -13,7 +13,7 @@ _This chapter was initially contributed as a tech note on rOpenSci website by [S
 
 ## Philosophy of changes {#philosophy-of-changes}
 
-Everyone's free to have their own opinion about how freely parameters/functions/etc. are changed in a library - rules about package changes are not enforced by CRAN or otherwise. Generally, as a library gets more mature, changes to user facing methods (i.e., exported functions in an R package) should become very rare. Libraries that are dependencies of many other libraries are likely to be more careful about changes, and should be.
+Everyone's free to have their own opinion about how freely parameters/functions/etc. are changed in a library - rules about package changes are not enforced by CRAN or otherwise. Generally, as a library gets more mature, changes to user-facing methods (i.e., exported functions in an R package) should become very rare. Libraries that are dependencies of many other libraries are likely to be more careful about changes, and should be.
 
 ## The lifecycle package {#the-lifecycle-package}
 
@@ -22,9 +22,9 @@ We recommend [reading the lifecycle documentation](https://lifecycle.r-lib.org/a
 
 ## Parameters: changing parameter names {#parameters-changing-parameter-names}
 
-Sometimes parameter names must be changed for clarity, or some other reason.
+Sometimes parameter names must be changed for clarity, or for some other reason.
 
-A possible approach is check if deprecated arguments are not missing, and stop providing a meaningful message.
+A possible approach is to check if deprecated arguments are not missing, and stop providing a meaningful message.
 
 ```r
 foo_bar <- function(x, y) {
@@ -53,7 +53,7 @@ foo_bar(x = 5)
 #> 25
 ```
 
-Be aware of the parameter `...`. If your function has `...`, and you have already removed a parameter (lets call it `z`), a user may have older code that uses `z`. When they pass in `z`, it's not a parameter in the function definition, and will likely be silently ignored -- not what you want. Instead, leave the argument around, throwing an error if it used.
+Be aware of the parameter `...`. If your function has `...`, and you have already removed a parameter (let's call it `z`), a user may have older code that uses `z`. When they pass in `z`, it's not a parameter in the function definition, and will likely be silently ignored -- not what you want. Instead, leave the argument around, throwing an error if it used.
 
 ## Functions: changing function names {#functions-changing-function-names}
 
@@ -126,7 +126,7 @@ foo <- function() {
 
 There's options in `.Deprecated` for specifying a new function name, as well as a new package name, which makes sense when moving functions into different packages.
 
-The message that's given by `.Deprecated` is a warning, so can be suppressed by users with `suppressWarnings()` if desired.
+The message that's given by `.Deprecated` is a warning, so it can be suppressed by users with `suppressWarnings()` if desired.
 
 Make a man page for deprecated functions like:
 
@@ -156,7 +156,7 @@ foo <- function() {
 }
 ```
 
-Note that the message in `.Defunct` is an error so that the function stops whereas `.Deprecated` uses a warning that let the function proceed.
+Note that the message in `.Defunct` is an error so that the function stops whereas `.Deprecated` uses a warning that lets the function proceed.
 
 In addition, it's good to add `...` to all defunct functions so that if users pass in any parameters they'll get the same defunct message instead of a `unused argument` message, so like:
 
@@ -201,7 +201,7 @@ This creates a man page that users can access like ``?`helloworld-defunct` `` an
 
 You don't have to change the tests of deprecated functions until they are made defunct.
 
-- Consider any changes made to a deprecated function. Along with using `.Deprecated` inside the function, did you change the parameters at all in the deprecated function, or create a new function that replaces the deprecated function, etc. Those changes should be tested if any made.
+- Consider any changes made to a deprecated function. Along with using `.Deprecated` inside the function, did you change the parameters at all in the deprecated function, or create a new function that replaces the deprecated function, etc. Those changes should be tested if any are made.
 - Related to above, if the deprecated function is simply getting a name change, perhaps test that the old and new functions return identical results.
 - [`suppressWarnings()` could be used](https://community.rstudio.com/t/unit-testing-of-a-deprecated-function/42837/2) to suppress the warning thrown from `.Deprecated`, but tests are not user facing, so it is not that bad if the warning is thrown in tests, and the warning could even be used as a reminder to the maintainer.
 
@@ -216,9 +216,9 @@ Renaming a package that is already widely adopted and/or released on CRAN is pro
 CRAN has a [policy](https://cran.r-project.org/web/packages/policies.html) stating that Package names on CRAN are persistent and in general it is not permitted to change a package’s name.
 The package under its old name might be a dependency of packages, scripts, and feature in documentation, scientific publications, and blog posts, etc.
 
-When radically changing the interface, starting a new package from scratch, like [httr2 which is the second generation of httr](https://www.tidyverse.org/blog/2023/11/httr2-1-0-0/) ; or creating editions of a package like for [testthat](https://testthat.r-lib.org/articles/third-edition.html), are better strategies. If you also maintain the old package, you can soft-deprecate it with a startup message, such as in httr.
+When radically changing the interface, starting a new package from scratch, like [httr2 which is the second generation of httr](https://www.tidyverse.org/blog/2023/11/httr2-1-0-0/); or creating editions of a package like for [testthat](https://testthat.r-lib.org/articles/third-edition.html), are better strategies. If you also maintain the old package, you can soft-deprecate it with a startup message, such as in httr.
 This allows users and package authors to choose when/whether to update their codebase to the new package or edition.
-If you copy code from another package, make sure to acknowledge authors of code you re-use by listing them in DESCRIPTION with a comment that states they were authors of the original package.
+If you copy code from another package, make sure to acknowledge authors of the code you reuse by listing them in DESCRIPTION with a comment that states they were authors of the original package.
 
 ## Archiving packages {#archivalguidance}
 

maintenance_github_grooming.Rmd

@@ -30,7 +30,7 @@ We might make suggestions to you after your package is onboarded.
 
 We recommend overriding GitHub linguist by adding or modifying a .gitattributes to your repo in two cases:
 
-- If you store html files in non standard places (not in docs/, e.g. in vignettes/) use the documentation overrides. Add `*.html linguist-documentation=true` to .gitattributes ([Example in the wild](https://github.com/ropensci/ecoengine/blob/56b64d8d29dfae430a776d1dd440b240452eb1bf/.gitattributes#L5))
+- If you store HTML files in non standard places (not in docs/, e.g. in vignettes/) use the documentation overrides. Add `*.html linguist-documentation=true` to .gitattributes ([Example in the wild](https://github.com/ropensci/ecoengine/blob/56b64d8d29dfae430a776d1dd440b240452eb1bf/.gitattributes#L5))
 
 - If your repo contains code you haven't authored, e.g. JavaScript code, add `inst/js/* linguist-vendored` to .gitattributes ([Example in the wild](https://github.com/ropensci/wellknown/blob/4435eb620eeae346d2cab7d62276c29dee29a898/.gitattributes#L1))
 

maintenance_marketing.Rmd

@@ -9,10 +9,10 @@ aliases:
 Also refer to the blog post ["Marketing Ideas For Your Package"](https://ropensci.org/blog/2024/03/07/package-marketing/).
 
 ```{block, type="summaryblock"}
-We will help you promoting your package but here are some more things to keep in mind.
+We will help you promote your package but here are some more things to keep in mind.
 ```
 
-- If you hear of an use case of your package, please encourage its author to post the link to our [discussion forum in the Use Cases category](https://discuss.ropensci.org/c/usecases), [for a toot (Mastodon post) from rOpenSci and inclusion in the rOpenSci monthly newsletter](https://discuss.ropensci.org/t/about-the-usecases-category/33). We also recommend you to add a link to the use case in a "use cases in the wild" section of your README.
+- If you hear of a use case of your package, please encourage its author to post the link to our [discussion forum in the Use Cases category](https://discuss.ropensci.org/c/usecases), [for a toot (Mastodon post) from rOpenSci and inclusion in the rOpenSci monthly newsletter](https://discuss.ropensci.org/t/about-the-usecases-category/33). We also recommend that you add a link to the use case in a "use cases in the wild" section of your README.
 
 - Post about your package on social media (Mastodon, Bluesky, LinkedIn...) using the "#rstats" hashtag and tag rOpenSci if rOpenSci is present on that platform! This might help with contributor/user engagement. Example posts from rOpenSci itself: [A package a day](hachyderm.io/@rOpenSci/111611705648653729), [Help wanted post](hachyderm.io/@rOpenSci/111460729804231877), [Use cases](hachyderm.io/@rOpenSci/111371091053569287), [Welcome post]( hachyderm.io/@rOpenSci/111342069863172097).
 
@@ -25,6 +25,6 @@ We will help you promoting your package but here are some more things to keep in
   - Submit your package to lists of packages such as [CRAN Task Views](https://cran.r-project.org/web/views/).
 
 - If you choose to market your package by giving a talk about it at a meetup or conference (excellent idea!)
-  read [this article of Jenny Bryan's and Mara Averick's](https://www.tidyverse.org/articles/2018/07/carpe-talk/).
+  read [this article by Jenny Bryan and Mara Averick](https://www.tidyverse.org/articles/2018/07/carpe-talk/).