diff --git a/Gemfile.lock b/Gemfile.lock
index 894648ca..2ddde455 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -346,7 +346,7 @@ GEM
       thor (~> 1.0, >= 1.2.2)
       zeitwerk (~> 2.6)
     rake (13.1.0)
-    rdoc (6.6.2)
+    rdoc (6.6.3.1)
       psych (>= 4.0.0)
     redis (5.1.0)
       redis-client (>= 0.17.0)
diff --git a/docs/editing.md b/docs/editing.md
index ec4ed11c..53a4dfa3 100644
--- a/docs/editing.md
+++ b/docs/editing.md
@@ -539,6 +539,7 @@ All new editors at JOSS have an onboarding call with an Editor-in-Chief. You can
 - Reinforce that this is a commitment, and thay regular attention to their submissions is absolutely critical (i.e., check in a couple of times per week).
 - Ask if they would like to move forward or would like time to consider the opportunity.
 - If they want to move forward, highlight they will receive a small number of invites: One to the JOSS editors GitHub team, a Slack invite, a Google Group invite, and an invite to the JOSS website to fill out their profile.
+- If they are joining the team, make sure they mark themselves as unavailable in the [JOSS reviewers database](https://reviewers.joss.theoj.org/) (so they don't get asked to review any longer).
 - Thank them again, and welcome them to the team.
 
 **Communicate outcome to EiC**
diff --git a/docs/submitting.md b/docs/submitting.md
index a9310a0b..b3411ba7 100644
--- a/docs/submitting.md
+++ b/docs/submitting.md
@@ -38,6 +38,12 @@ As a rule of thumb, JOSS' minimum allowable contribution should represent **not
 
 In addition, JOSS requires that software should be feature-complete (i.e., no half-baked solutions), packaged appropriately according to common community standards for the programming language being used (e.g., [Python](https://packaging.python.org), [R](https://r-pkgs.org/index.html)), and designed for maintainable extension (not one-off modifications of existing tools). "Minor utility" packages, including "thin" API clients, and single-function packages are not acceptable.
 
+#### A note on web-based software
+
+Many web-based research tools are out of scope for JOSS due to a lack of modularity and challenges testing and maintaining the code. Web-based tools may be considered 'in scope' for JOSS, provided that they meet one or both of the following criteria: 1) they are are built around and expose a 'core library' through a web-based experience (e.g., R/[Shiny](https://www.rstudio.com/products/shiny/) applications) or 2) the web application demonstrates a high-level of rigor with respect to domain modeling and testing (e.g., adopts and implements a design pattern such as [MVC](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) using a framework such as [Django](https://www.djangoproject.com/)).
+
+Similar to other categories of submission to JOSS, it's essential that any web-based tool can be tested easily by reviewers locally (i.e., on their local machine). 
+
 ### Co-publication of science, methods, and software
 
 Sometimes authors prepare a JOSS publication alongside a contribution describing a science application, details of algorithm development, and/or methods assessment. In this circumstance, JOSS considers submissions for which the implementation of the software itself reflects a substantial scientific effort. This may be represented by the design of the software, the implementation of the algorithms, creation of tutorials, or any other aspect of the software. We ask that authors indicate whether related publications (published, in review, or nearing submission) exist as part of submitting to JOSS.