fix: add more direction on labels and tracking reviews to editor guide (pyOpenSci#339)

Author: lwasser

how-to/editor-in-chief-guide.md

@@ -96,7 +96,21 @@ responding to out-of-scope pre-submissions.
 If the EiC has limited time to handle [pre-review checks](pre-review-checks) for a package, a conflict of interest, or lacks relevant expertise, they may ask another editor to perform initial checks on a package at any time.
 :::
 
-## Editor in Chief checklist
+## Editor in Chief pre-review submission checklist
+
+The EiC is also responsible for determining the scope of packages submitted via a pre-submission inquiry.
+
+The steps include:
+
+1. **Determine if the package is in scope for review:** Have a look at the pre-submission inquiry. Use our [project scope page](https://www.pyopensci.org/software-peer-review/about/package-scope.html) to determine whether that package is in scope for pyOpenSci review.
+2. If the package is in scope, add the `submission-requested` label to the pre-submission inquiry.
+3. Let the author know that `pre-review` checks are next and will happen in the full submission issue. At this stage, it's a good idea to let the author know that the package will undergo pre-review checks upon submission for review. You can share the [pre-review checks template with the author at this time if you wish](editor-checklist-template)
+
+:::{note}
+It is OK to perform pre-review checks in the pre-review submission if you wish. However, for documentation purposes, you will need to perform them in the full submission issue, as that is what JOSS and other partners look at. Be sure that you aren't duplicating your time!
+:::
+
+## Editor in Chief peer review checklist
 
 When a new package is submitted for review, the Editor in Chief should:
 
@@ -127,6 +141,9 @@ existing community, please check below:
 (pre-review-checks)=
 ### 3. ✔️ Add the pre-review checks to the issue
 
+When you add `pre-review` checks to the issue, remove the `New Submission!` label from the issue.
+This lets people know that someone is working on the issue and moving it forward.
+
 :::{important}
 Post your complete pre-review/editor checks in **one single comment**, rather than in multiple
 comments. This keeps the review easy to follow and lets the author address
@@ -179,8 +196,8 @@ to check which editors are currently available and what domains those editors ar
 
 Once you’ve selected an editor:
 
-1. Assign the issue to them in GitHub
-2. Update the YAML at the top of the issue with their GitHub username
+1. **Assign the issue to that editor in GitHub** This step helps us keep track of who is running which reviews. Please do not forget to do this!
+2. Update the editor section of the YAML at the top of the issue with their GitHub username
 3. Add the `1/editor-assigned` label to the issue
 
 :::{note}

how-to/editors-guide.md

@@ -115,11 +115,21 @@ referenced multiple times in the steps below:
 
 ```
 
-### ✔️ 1. First, tag the submission issue on GitHub
+### ✔️ 1. First, tag the submission issue on GitHub & assign yourself to the issue
 
 Once you begin the review process as an editor:
 
 - Tag the submitted GitHub issue with the `1/editor-checks` tag if it hasn't already been tagged by the editor-in-chief.
+- Make sure that you are assigned to the issue on GitHub (ie, your name is on the right-hand side of the issue as the person running it).
+
+:::{figure-md} assign-editor
+
+<img src="../images/assign-issue.png" alt="Screenshot showing the right-hand side of a GitHub issue with the editor assigned to the issue." width="700px">
+
+Make sure that your name is both listed in the YAML at the top of the issue and also that you are assigned to the issue on GitHub (on the right-hand side of the issue).
+:::
+
+
 - Check the YAML template at top of the submitted GitHub issue, make sure that mandatory parts of the template are filled out.
   - If elements are incomplete, direct the authors toward filling in any missing pieces.
 
@@ -135,17 +145,17 @@ Version submitted: VERSION-SUBMITTED
 ```{admonition} Editor in Chief checks for structure & scope should be completed first
 :class: note
 
-The editor in chief who initially engaged with this review should have already evaluated the package level Editor Checks section for `Fit`, `Automated Tests`, `Documentation`, `License`, and `Repository`.
+The editor in chief who initially engaged with this review should have already evaluated the package-level Editor Checks section for `Fit`, `Automated Tests`, `Documentation`, `License`, and `Repository`.
 
 They also should have checked whether the package is [in scope for pyOpenSci](../about/package-scope).
 And whether there is [functionality overlap with functionality of any other existing Python packages](package-overlap).
 
-However, in some instances the editor-in-chief may request that an editor
-perform these tasks. Be sure to check the issue to ensure the above checks have been implemented prior to initiating the review.
+However, in some instances, the editor-in-chief may request that an editor
+perform these tasks. Be sure to check the issue to ensure the above checks have been implemented before initiating the review.
 
 If the package does not fit the pyOpenSci scope and policies and needs to be
 rejected, see
-[this section in the editor in chief guide](editor-in-chief-guide.md#responding-to-out-of-scope-submissions)
+[this section in the editor-in-chief guide](editor-in-chief-guide.md#responding-to-out-of-scope-submissions)
 about how to respond.
 ```
 
@@ -257,6 +267,7 @@ ensure that things are moving smoothly:
 - Check in with reviewers and authors occasionally. Offer clarification and help as needed.
 - Aim for ~3 weeks for review, 2 weeks for subsequent changes, and 1 week for reviewer approval of changes.
 - If a review has not been submitted after 2 weeks, ping the reviewer(s) within the review issue to ensure they are aware of the 3-week deadline.
+- If you are waiting for a maintainer to respond to you, be sure to add the label `pending-maintainer-response` to the issue.
 
 ### ✔️ 5. What to do when reviews are in