Update softwarereview_reviewer.Rmd

Author: Moohan

softwarereview_reviewer.Rmd

@@ -6,17 +6,17 @@ aliases:
 # Guide for Reviewers {#reviewerguide}
 
 ```{block, type="summaryblock"}
-Thanks for accepting to review a package for rOpenSci! This chapter consists of our guidelines to [prepare](#preparereview), [submit](#submitreview) and [follow up](#followupreviewer) on your review.
+Thanks for agreeing to review a package for rOpenSci! This chapter consists of our guidelines to [prepare](#preparereview), [submit](#submitreview) and [follow up](#followupreviewer) on your review.
 
-You might contact the editor in charge of the submission for any question you might have about the process or your review.
+You might contact the editor in charge of the submission for any questions you might have about the process or your review.
 
 Please strive to complete your review within 3 weeks of accepting a review request. We will aim to remind reviewers of upcoming and past due dates. Editors may assign
 additional or alternate reviewers if a review is excessively late.
 
 **rOpenSci's community is our best asset. 
 We aim for reviews to be open, non-adversarial, and focused on improving software quality. 
 Be respectful and kind! 
-See our reviewers guide and [code of conduct](https://ropensci.org/code-of-conduct/) for more.**
+See our reviewers' guide and [code of conduct](https://ropensci.org/code-of-conduct/) for more.**
 
 _If you use our standards/checklists etc. when reviewing software elsewhere, do tell the recipients (e.g. journal editors, students, internal code review) that they came from rOpenSci, and tell us in [our public forum](https://discuss.ropensci.org/c/usecases), or [privately by email](https://ropensci.org/contact/)._ 
 ```
@@ -29,7 +29,7 @@ Please fill our [volunteering form](https://ropensci.org/software-reviewer).
 
 If you see a current submission that is particularly relevant to your interests please email `info@ropensci.org`, including the name of the package, the URL to the submission issue and the name of the assigned editor.
 However, keep in mind that reviewer invitations are kept at the editor's discretion, and the editor might well have already emailed people.
-Please do not volunteer for all issues, and do not volunteer via GitHub interface.
+Please do not volunteer for all issues, and do not volunteer via the GitHub interface.
 
 For other ways to contribute, refer to [rOpenSci contributing guide](https://contributing.ropensci.org/).
 
@@ -45,7 +45,7 @@ To review a package, please begin by copying our [review template](#reviewtempla
 - Does the package comply with the [rOpenSci packaging guide](#building)?
 - Are there improvements that could be made to the code style and to code patterns? For instance, do functions need to be broken down into smaller helper functions and is the role of each helper function clear?
 - Is there code duplication in the package that should be reduced?
-- Are there functions in base R or lightweight dependency that provide the same interface as some helper functions in the package?
+- Are there functions in base R or lightweight dependencies that provide the same interface as some helper functions in the package?
 - Are there user interface improvements that could be made?
 - Are there performance improvements that could be made?
 - Is the documentation (installation instructions/vignettes/examples/demos) clear and sufficient? Does it use the principle of *multiple points of entry* i.e. takes into account the fact that any piece of documentation may be the first encounter the user has with the package and/or the tool/data it wraps?
@@ -55,21 +55,21 @@ To review a package, please begin by copying our [review template](#reviewtempla
 
 Please be respectful and kind to the authors in your reviews. Our [code of conduct](#code-of-conduct) is mandatory for everyone involved in our review process. We expect you to submit your review within 3 weeks, depending on the deadline set by the editor. Please contact the editor directly or in the submission thread to inform them about possible delays.
 
-We encourage you to use automated tools to facilitate your reviewing.  These include:
+We encourage you to use automated tools to facilitate your review.  These include:
 
 - Checking the initial package report generated by our `@ropensci-review-bot`.
 - Checking the package's logs on its continuous integration services (GitHub Actions, Codecov, etc.)
 - Running `devtools::check()` and `devtools::test()` on the package to find any errors that may be missed on the author's system.
 - Seeing whether tests' skipping is justified (e.g. `skip_on_cran()` tests that do real API requests vs. skipping all tests on one operating system).
-- If the package is not submitted via the default/main branch, remember to switch to the submitted review branch before starting your review. In this case, you will also have to search the package locally, as GitHub search is limited to the default branch. Further, documentation hosted on a `pkgdown` website is not necessarily up-to-date, and we recommend to inspect the package's documentation locally by running `pkgdown::build_site()`.
+- If the package is not submitted via the default/main branch, remember to switch to the submitted review branch before starting your review. In this case, you will also have to search the package locally, as GitHub search is limited to the default branch. Further, documentation hosted on a `pkgdown` website is not necessarily up-to-date, and we recommend inspecting the package's documentation locally by running `pkgdown::build_site()`.
 
 Reviewers may also re-generate package check results from `@ropensci-review-bot` at any time by issuing the single comment in a review issue: `@ropensci-review-bot check package`.
 
 Some items in our checklist were inspired by the [Mozilla code review guide](https://mozillascience.github.io/codeReview/review.html).
 
 ### Off-thread interactions {#off-thread-interactions}
 
-If you interact with the package authors and talked about the review outside a review thread (in chats, DMs, in-person, issues in the project repository), please make sure that your review captures and/or links to elements from these conversations that are relevant to the process.
+If you interact with the package authors and talk about the review outside a review thread (in chats, DMs, in-person, issues in the project repository), please make sure that your review captures and/or links to elements from these conversations that are relevant to the process.
 
 ### Experience from past reviewers {#experience-from-past-reviewers}
 
@@ -83,9 +83,9 @@ First-time reviewers may find it helpful to read (about) some previous reviews.
 
 - `rusda` [review](https://github.com/ropensci/software-review/issues/18#issuecomment-120445737) (from before we had a review template)
 
-You can read blog posts written by reviewers about their experiences [via this link](https://ropensci.org/tags/reviewer/). In particular, in [this blog post by Mara Averick](https://ropensci.org/blog/2017/08/22/first-package-review/) read about the "naive user" role a reviewer can take to provide useful feedback even without being experts of the package's topic or implementation, by asking themselves *"What did I think this thing would do? Does it do it? What are things that scare me off?"*. In [another blog post](https://ropensci.org/blog/2017/09/08/first-review-experiences/) Verena Haunschmid explains how she alternated between using the package and checking its code.
+You can read blog posts written by reviewers about their experiences [via this link](https://ropensci.org/tags/reviewer/). In particular, in [this blog post by Mara Averick](https://ropensci.org/blog/2017/08/22/first-package-review/) read about the "naive user" role a reviewer can take to provide useful feedback even without being an expert in the package's topic or implementation, by asking themselves *"What did I think this thing would do? Does it do it? What are the things that scare me off?"*. In [another blog post](https://ropensci.org/blog/2017/09/08/first-review-experiences/) Verena Haunschmid explains how she alternated between using the package and checking its code.
 
-As both a former reviewer and package author, and now editor, [Adam Sparks](https://adamhsparks.netlify.app/) wrote "\[write\] a good critique of the package structure and best coding practices. If you know how to do something better, tell me. It's easy to miss documentation opportunities as a developer, as a reviewer, you have a different view. You're a user that can give feedback. What's not clear in the package? How can it be made more clear? If you're using it for the first time, is it easy? Do you know another R package that maybe I should be using? Or is there one I'm using that perhaps I shouldn't be? If you can contribute to the package, offer."
+As both a former reviewer and package author, and now editor, [Adam Sparks](https://adamhsparks.netlify.app/) wrote "\[write\] a good critique of the package structure and best coding practices. If you know how to do something better, tell me. It's easy to miss documentation opportunities as a developer, but as a reviewer, you have a different view. You're a user that can give feedback. What's not clear in the package? How can it be made more clear? If you're using it for the first time, is it easy? Do you know another R package that maybe I should be using? Or is there one I'm using that perhaps I shouldn't be? If you can contribute to the package, offer."
 
 ### Helper package for reviewers {#helper-package-for-reviewers}