Add: holding language to editor guide and other edigs

Author: lwasser

about-peer-review/how-peer-review-works.md

@@ -42,7 +42,12 @@ We use GitHub because:
 * We label issues to track every step of the package submission and review progress (e.g. [1/initial-editor-checks, 2/reviewers-needed, 6/pyopensci-approved](https://github.com/pyOpenSci/software-review/labels)
 
 ```{note}
-Click [here](https://github.com/ropensci/software-review/issues/24) to read the review thread from an rOpenSci review of the `ropenaq` package. Note that the  process is an ongoing conversation until the package is accepted. Two external reviews are important milestones in the review process. 
+[Click here to read the review thread from a December 2022 
+pyOpenSci pre-submission issue.](https://github.com/pyOpenSci/software-review/issues/65) Note the conversational 
+tone of the pre-review. In this case the package was improved 
+Before the formal review even began. 
+
+In the actual review process, two external reviews are important milestones. The editor will also provide the author with some feedback.
 ```
 
 For more detailed overview of the peer review process, [check out our process 

about-peer-review/policies-guidelines.md

@@ -2,31 +2,25 @@
 
 ## Review Process Guidelines
 
-- Packages are reviewed for quality, fit, documentation, clarity and the review process
-  is quite similar to a manuscript review (see our [packaging guide](../authoring/overview)
-  and [reviewing guide](../peer-review-guides/reviewer-guide) for more details). Unlike a
-  manuscript review, this process will be an ongoing conversation.
-- Once all major issues and questions, and those addressable with reasonable effort, are
-  resolved, the editor assigned to a package will make a decision (accept, hold, or
-  reject). Rejections are usually done early (before the review process begins, see the
-  aims and scope section). In rare cases a package may also not be on-boarded after
-  review & revision. It is ultimately editor’s decision on whether or not to reject the
-  package based on how the reviews are addressed.
-- Communication between authors, reviewers and editors will first and foremost take
-  place on GitHub, although you can choose to contact the editor by email. When
-  submitting a package, please make sure your GitHub notification settings make it
-  unlikely you will miss a comment.
-- The author can choose to have their submission put on hold (editor applies the holding
-  label). The holding status will be revisited every 3 months, and after one year the
-  issue will be closed.
-- If the author hasn’t requested a holding label, but is simply not responding, we
-  should close the issue within one month after the last contact intent. This intent
-  will include a comment tagging the author, but also an email using the email address
-  listed in the DESCRIPTION of the package which is one of the rare cases where the
-  editor will try to contact the author by email.
-- If a submission is closed and the author wishes to re-submit, they’ll have to start a
-  new submission. If the package is still in scope, the author will have to respond to
-  the initial reviews before the editor starts looking for new reviewers.
+pyOpenSci packages are reviewed for quality, fit, scope, 
+documentation and usability. The review process
+is similar to a manuscript review, however it has a stronger 
+focus on Python packaging best practices. 
+
+Unlike a manuscript review, our peer review process is be an ongoing conversation. Once all major issues and questions are addressed, the review editor package will make a decision to accept, hold, or reject the package. 
+
+Rejections are usually done early in the process, before the review process begins. In rare cases a package may also not be on-boarded into the pyOpenSci ecosystem after review & revision. 
+
+It is ultimately editor’s decision on whether or not to reject the package based on how the reviews are addressed.
+
+## Review communication approach 
+
+Communication between authors, reviewers and editors takes 
+place on GitHub. You can, however choose to contact the editor by email if needed. 
+
+When submitting a package, please make sure that your GitHub notification settings are setup to notify you when you receive feedback on the review issue. 
+
+
 
 ## Submitting your package for review in other venues
 

appendices/editor-in-chief-checks.md

@@ -6,6 +6,8 @@ review. Below are the basic checks that your package needs to pass
 to begin our review. If some of these are missing, we will ask you 
 to work on them before the review process begins. 
 
+- [ ] **Installation** The package can be installed from a community repository such as PyPI (preferred), and/or a community channel on conda (e.g. conda-forge, bioconda)
+  - [ ] The package imports properly into a standard Python environment `import package-name`
 - [ ] **Fit**: The package meets criteria for [fit](https://www.pyopensci.org/peer-review-guide/about-peer-review/aims-and-scope.html#package-scope) and [overlap](https://www.pyopensci.org/peer-review-guide/about-peer-review/aims-and-scope.html#package-overlap).
 - [ ] **Documentation** The package has sufficient documentation available online (README, sphinx docs) to allow us to evaluate package function and scope *without installing the package*. This includes:
   - [ ] Short tutorials or [vignettes](https://kbroman.org/pkg_primer/pages/vignettes.html) that help a user understand how to use the package and what it can do for them (often these have a name like "Getting started")

software-peer-review-guide/editor-in-chief-guide.md

@@ -44,6 +44,17 @@ When a new package is submitted for review, the Editor in Chief will:
 
 ### 2. ✔️ Add the editor checks to the issue 
 
+```{important}
+It is important that this step occur in one post rather than a string of 
+conversational feedback that is more difficult to follow. This allows the author to address all issues at 
+one time. Thus the EIC should:
+
+1. Review the checklist
+1. Give the author a rough estimate of how long the checks might take to complete
+1. Perform all of the checks locally
+1. When all of the above are complete, post the checklist with any feedback for the author in the issue. This should be one single post. 
+```
+
 Copy the {ref}`template below <editor-checklist-template>` 
 and add it to the issue. 
 

software-peer-review-guide/editors-guide.md

@@ -239,6 +239,34 @@ Be sure to:
 review next time (e.g. a package author who has already submitted packages to us).
 ```
 
+## Putting a review on hold & handling non-responsive authors 
+
+In some cases, an author may need more time to respond to 
+review comments. In this case, the author can choose to have 
+their submission put on hold. As an editor you should apply the `holding label` to the GitHub issue. 
+
+The holding status will be revisited every 3 months. 
+
+After one year the issue will be closed if there is no movement towards responding to reviews by the author.
+
+If the author simply not responding, the editor should:
+
+* Tag the author (`@author-github-handle`) in an issue comment notifying them that we will close ths issue in one month if there is no response. 
+* Close the issue if one month has passed without a reply. 
+
+If needed you can also chose to email the author. using the email provided in the package metadata file of the package. The email 
+could be in any of the three files in the package: `setup.py`, `pyproject.toml` (preferred) or `setup.cfg`. 
+
+```{important}
+If a submission is closed and the author wishes to re-submit, they will have to start a new submission. 
+
+If the package is still in scope, the author will have to 
+respond to the first round of reviews first. After that is 
+complete, you can begin looking for new reviewers to 
+evaluated the package. This ensures that none of the review 
+energy spent in the first review, goes to waste. 
+```
+
 ### ✔️ 6. How to accept a package into the pyOpenSci ecosystem
 
 Once the package has been accepted through the review process: