docs: simplify CONTRIBUTING.md to reflect current state

CONTRIBUTING.md

@@ -12,51 +12,27 @@ source communities help us along the way.
     [reproduction step guidelines](https://github.com/LLK/scratch-gui/wiki/Writing-good-repro-steps).
     * Some issues are marked "Needs Repro". Adding a comment with good reproduction steps to those issues is a great
       way to help.
-  * If you don't have an issue in mind already, you can look through the [Bugs & Glitches forum.](
-    https://scratch.mit.edu/discuss/3/) Look for users reporting problems, reproduce the problem yourself, and file
+  * If you don't have an issue in mind already, you can look through the [Bugs & Glitches forum](
+    https://scratch.mit.edu/discuss/3/). Look for users reporting problems, reproduce the problem yourself, and file
     new issues following our guidelines.
 
 * **Fixing bugs**
-  * **We will only accept Pull Requests for bugs that have an issue filed with a priority label**
-    * If you're interested in fixing a bug that does not have an issue already, please file the issue first and wait
-      for it to have a priority added to it.
-  * You can request to fix a bug in a comment on the issue if you mention the repo coordinator for this repository,
-    using the @ symbol with their Github username. Check the list of [Repository Coordinators](
-    ./CONTRIBUTING.md#repository-coordinators) to find out who to @-mention.
+  * **We will prioritize Pull Requests for bugs that have an issue filed, especially those with a priority label**
+    * If you're interested in fixing a bug that does not have an issue already, please file an issue first. This helps
+      us avoid making the same mistake again later, and speeds up fixing it if we do.
+  * If you plan to work on an issue, please leave a comment on the issue to let us and other contributors know you're
+    working on it.
     * The "help wanted" label indicates issues that the Scratch Team thinks would be appropriate for an external
-      contributor to work on. You should still wait for an issue to be prioritized before working on it or submitting
-      a PR.
+      contributor to work on.
   * We are not looking for Pull Requests ("PR") for every issue and may deny a PR if it doesn't fit our criteria.
     * We are far more likely to accept a PR if it is for an issue marked with the "Help Wanted" label.
     * We will not accept PRs for issues marked with "Needs Discussion" or "Needs Design."
-    * Wait until an issue has been assigned a priority before working on it. Also leave a comment if you start working
-      on a prioritized issue, so other people don't start working on it also.
-
-## Repository Coordinators
-
-Public repositories where we encourage contributions have a repository coordinator. Here are the current assignments:
-
-* scratch-audio @ericrosenbaum
-* scratch-blocks @ericrosenbaum
-* scratch-desktop @cwillisf
-* scratch-gui @chrisgarrity
-* scratch-link @cwillisf
-* scratch-render @cwillisf
-* scratch-storage @cwillisf
-* scratch-svg-renderer @cwillisf
-* scratch-vm @ericrosenbaum
-* scratch-www @benjiwheeler
-* scratchjr @chrisgarrity
-* scratchjr-website @chrisgarrity
-
-Repositories that do not accept external PRs:
-
-* scratch-l10n
-* scratch-paint
-* scratch-parser
-* scratch-render-fonts
-* scratch-resources
-* scratch-sb1converter
+  * Keep in mind that we are also making our own changes, and may not be able to respond in detail to every
+    contribution. We appreciate your patience and understanding. A few reasons we might need to delay a PR include:
+    * We are working on other changes in the same area of the codebase
+    * We want to limit the number of changes we make to the codebase in a given time period to limit the risk or QA
+      load for a release
+    * We are just short on time (it's usually this one - sorry!)
 
 ## Learning Git and Github
 
@@ -74,11 +50,11 @@ process.
 
 1. Identify which Github issue you are working on. Leave a comment on the issue to let us (and other contributors)
    know you're working on it.
-2. Make sure you have a fork of this repo (see [Github's forking a repo](
+2. Make sure you have a fork of the repo (see [Github's forking a repo](
    https://help.github.com/en/github/getting-started-with-github/fork-a-repo) for details)
-3. Switch to the `develop` branch, and pull down the latest changes from upstream
+3. Switch to the primary branch (usually `develop` or `main`), and pull down the latest changes from upstream
 4. Run the code, and reproduce the problem
-5. Create your branch from the `develop` branch
+5. Create your branch from the primary branch
 6. Make code changes to fix the problem
 7. Test your changes and make sure existing tests pass. In most scratch repositories running `npm test` will run the
    tests. We strongly encourage you to write tests for any changes.
@@ -120,7 +96,7 @@ simple, even hand-drawn.
 Beyond this repo, there are also some other resources that you might want to take a look at:
 
 * [Community Guidelines](https://github.com/LLK/scratch-www/wiki/Community-Guidelines) (we find it important to
-  maintain a constructive and welcoming community, just like on Scratch)
+  maintain a constructive and welcoming developer community, just like on Scratch)
 * [Open Source forum](https://scratch.mit.edu/discuss/49/) on Scratch
 * [Suggestions forum](https://scratch.mit.edu/discuss/1/) on Scratch
 * [Bugs & Glitches forum](https://scratch.mit.edu/discuss/3/) on Scratch