General updates to various wiki pages based on issues noted over the past few months.

Adding-new-translations-for-i18n.md

@@ -38,7 +38,7 @@ In this example, the # symbol will be replaced by the value of the `notification
 In general, it is better to add translations via the translatewiki UI where possible. However, in exceptional cases, you can manually add a language to the Oppia codebase in three simple steps:
 
 1. Copy [assets/i18n/en.json file](https://github.com/oppia/oppia/blob/develop/assets/i18n/en.json) into a new file called `xx.json`, where xx is the language code for the new language. You can find this code [here](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes). Save the resulting file in the same `i18n/` directory.
-2. Replace all occurrences of English with the translated phrase in the target language. It's OK if you omit some translations, but please ensure to remove all occurrences of English translations from the file as when a translation key is missing, the English variant will be used as a fall-back. Please refer to the notes below on how to handle variables and pluralization during translation. Please also see [qqq.json](https://github.com/oppia/oppia/blob/develop/assets/i18n/qqq.json) for important contextual information about what is being translated, and feel free to ask questions on oppia-dev@ or [GitHub Discussions](https://github.com/oppia/oppia/discussions) if anything is unclear!
+2. Replace all occurrences of English with the translated phrase in the target language. It's OK if you omit some translations, but please ensure to remove all occurrences of English translations from the file as when a translation key is missing, the English variant will be used as a fall-back. Please refer to the notes below on how to handle variables and pluralization during translation. Please also see [qqq.json](https://github.com/oppia/oppia/blob/develop/assets/i18n/qqq.json) for important contextual information about what is being translated, and feel free to ask questions on [GitHub Discussions](https://github.com/oppia/oppia/discussions) if anything is unclear!
 3. In [feconf.py](https://github.com/oppia/oppia/blob/develop/feconf.py), add a new entry to the variable  `SUPPORTED_SITE_LANGUAGES` representing the language code and the language name.
 
 After this, you should be able to see the new language listen in the Oppia splash page and translate the site  using the language dropdown in the footer.

Apache-Beam-Jobs.md

@@ -611,7 +611,7 @@ In order to run jobs through the local dev server you need to have JSON key that
 
 Even though it is possible to use NDB functions directly, they should not be used because they are slow and we have Beam compliant alternatives from them. All these alternatives are located in _core/jobs/io/ndb_io.py_.
 
-- Instead of using `get`, `get_multi`, `get_by_id`, etc. you should use `GetModels`, and you should pass a query to it, `GetModels` will execute the query and return a `PCollection` of the models that were returned by the query. 
+- Instead of using `get`, `get_multi`, `get_by_id`, etc. you should use `GetModels`, and you should pass a query to it, `GetModels` will execute the query and return a `PCollection` of the models that were returned by the query.
 - Instead of using `put`, `put_multi`, etc. you should use `PutModels`, and you just pipe a `PCollection` of models to it and they will be put into the datastore.
 - Instead of using `delete`, `delete_multi`, etc. you should use `DeleteModels`, and you just pipe a `PCollection` of models to it and they will be deleted from the datastore.
 
@@ -676,7 +676,7 @@ The code above throws this error `'_UnwindowedValues' object is not subscriptabl
 
 ### `_namedptransform is not iterable` error
 
-This error sometimes happens when you forget to add a label for some operation (the strings of code before `>>`). The solution is to add a label for all operations. 
+This error sometimes happens when you forget to add a label for some operation (the strings of code before `>>`). The solution is to add a label for all operations.
 
 #### Example
 
@@ -702,14 +702,15 @@ This section provides some general guidelines for writing Beam jobs, which would
     * [Story migration job](https://github.com/oppia/oppia/blob/fc2e383032a0f9308fdde03d7efd10971752bacf/core/jobs/batch_jobs/story_migration_jobs.py#L60)
 * There should also be a job to verify the changes done by your job.
 * Consider the example of topic migration job. The [AuditTopicMigrateJob](https://github.com/oppia/oppia/blob/fc2e383032a0f9308fdde03d7efd10971752bacf/core/jobs/batch_jobs/topic_migration_jobs.py#L355) is the audit job which performs all the steps in the main job ([MigrateTopicJob](https://github.com/oppia/oppia/blob/fc2e383032a0f9308fdde03d7efd10971752bacf/core/jobs/batch_jobs/topic_migration_jobs.py#L244)), except it doesn't write those changes to the datastore.
+* It is often helpful to include debugging information with your job from the outset, since modifying a failed job and rerunning it can take time. Feel free to include additional logs or counts that will help you debug any issues that arise during execution. To help you identify these easily, you can prefix the relevant lines of output with an identifier in square brackets (e.g. `[NUMBER OF MODELS PROCESSED]`).
 
 ### Executing jobs
 * Refer to code from similar jobs to avoid mistakes. The "Troubleshooting" section in the wiki lists common errors encountered while executing jobs.
 * Make sure to write tests for all jobs. These tests should check the behaviour of the job for different cases of inputs. The common cases for all jobs are listed below:
     * Empty input.
     * Input which triggers the job to perform its intended action.
     * Incorrect input which causes the job to fail.
-* The tests should ensure that the job runs appropriately for all such cases. 
+* The tests should ensure that the job runs appropriately for all such cases.
 
 ### PR guidelines
 * A PR for a Beam job should always have "Proof of work" in the description which should include the successful local run of the Beam job on the release coordinator page and a screenshot of the storage model which is being changed. The storage models can be checked [locally](https://github.com/oppia/oppia/wiki/Debugging-datastore-locally) via dsadmin.

Contributing-code-to-Oppia.md

@@ -78,13 +78,15 @@ Welcome! Please make sure to follow the instructions above if you haven't alread
 
 After that, you can choose a good first issue from the [list of good first issues](https://github.com/oppia/oppia/labels/good%20first%20issue). These issues are hand-picked to ensure that you don't run into unexpected roadblocks while working on them, and each of them should have clear instructions for new contributors. If you see one that doesn't, please let us know via [GitHub Discussions](https://github.com/oppia/oppia/discussions) and we'll fix it. For other issues, you might need to be more independent because we might not know how to solve them either.
 
+Please only work on issues that are labelled **"Impact: High"** or **"Impact: Medium"**. (We are not focusing on "Impact: Low" or "Backlog" issues for now; if you submit a fix for those, you will likely be redirected. We also recommend not working on "triage needed" issues since these might get closed or modified during the weekly triage process.)
+
 As a new contributor, if you run into any problems along the way, we're here to help! Check out our [[Getting Help Page|Get-help]] for the communication channels you can use.
 
 You can also browse good first issues for each of the core Oppia Web teams to find something you'd enjoy working on! Please only choose issues that have **not yet** been assigned, unless the issue is a "checkbox issue" with multiple claimable parts. Here are the project boards for the different teams:
 
+- Developer Workflow: https://github.com/orgs/oppia/projects/8/views/10, typically backend or frontend
 - Learner and Creator Experience (LaCE): https://github.com/orgs/oppia/projects/3/views/10, typically frontend or full-stack
 - Contributor Dashboard: https://github.com/orgs/oppia/projects/18/views/5, typically frontend or full-stack
-- Developer Workflow: https://github.com/orgs/oppia/projects/8/views/10, typically backend or frontend
 
 ### How to tackle good first issues
 
@@ -100,9 +102,11 @@ Once you have a good understanding of the issue, you can ask for it to be assign
 - Explain clearly how you'd tackle the issue (at a minimum, point to which file(s) you'd modify and describe the changes you'd make). If possible, show a screenshot or code snippet demonstrating your proposed fix.
 - @-mention the leads of the corresponding project (you can find their details [here](https://github.com/orgs/oppia/projects)), letting them know you'd like to work on it and when you can submit a PR by.
 
-If your explanation makes sense, we'll assign the issue to you. Once assigned, feel free to submit a PR by following the [[instructions for making a PR|Make-a-pull-request]].
+If your explanation makes sense, we'll assign the issue to you. Once assigned, feel free to submit a PR by following the [[instructions for making a PR|Make-a-pull-request]]. We recommend actively working to get your PR merged once you are assigned, because we will de-assign contributors if the PR is closed for being stale or there is no activity after the initial assignment.
+
+Generally, we aim to review PRs within 48 hours. If you have not heard from a reviewer by then, feel free to escalate. You can leave a comment on the review thread and also add a message to the "Contacting Folks" section of [GitHub Discussions](https://github.com/oppia/oppia/discussions/categories/q-a-contacting-folks).
 
-If you run into any problems, feel free to create a [GitHub Discussion](https://github.com/oppia/oppia/discussions) and get help from the Oppia community, or [request a mentor](https://forms.gle/udsRP4WQgLcez9Zm8) if you'd like individual support.
+If you run into any problems, feel free to create a [GitHub Discussion](https://github.com/oppia/oppia/discussions) and get help from the Oppia community, or [request a mentor](https://forms.gle/udsRP4WQgLcez9Zm8) if you'd like individual support. If you need specific help, write a [[debugging doc|Debugging-Docs]] to compile the necessary information and outline your thought process, so that we can help you more easily.
 
 **Important Note**: Please follow the [[PR instructions|Make-a-pull-request]] carefully! Otherwise your PR review may be delayed or your PR may be closed.
 
@@ -140,7 +144,7 @@ There are lots of options!
 
 * **Want to lead a project?** Let us know by emailing [email protected].  We may offer you the opportunity to do this once you've sent in several good PRs.
 
-* **Want help figuring out what to do?** Just ask us on [GitHub Discussions](https://github.com/oppia/oppia/discussions), or send an email to [email protected]. We'll try to help!
+* **Want help figuring out what to do?** Just ask us on [GitHub Discussions](https://github.com/oppia/oppia/discussions). We'll try to help!
 
 If an issue hasn't got someone assigned to it, and there's no existing PR for the issue (you can check this by scanning the list of [existing PRs](https://github.com/oppia/oppia/pulls)), feel free to take it up by assigning yourself to it, and let the corresponding team lead know. Also, if you need help or advice on an issue, you can contact the corresponding team lead. See the [Projects page](https://github.com/oppia/oppia/projects) for details of who the team leads are.
 
@@ -193,4 +197,4 @@ If an issue hasn't got someone assigned to it, and there's no existing PR for th
 
   ![Screenshot showing the blame button on GitHub](images/githubBlame.png)
 
-* **Important** PRs marked with the “critical” label need to be tested in the backup server before being merged. For this, one of the release coordinators (with access to deploy) should checkout a new branch from develop, merge the branch from the PR into the new branch, and initiate deployment to the backup server from this branch. The PR author should give specific testing instructions for the changes (like which job to run, what the expected output is, etc) and the coordinator should verify the same. Once successfully tested, the PR should be merged into develop. This is to prevent cases like exploration migrations which can result in data corruption (as it will auto-migrate) if the migration isn’t safe. The "critical" label needs to be applied on PRs that change data validation checks, and other possibly critical changes which could affect production data.
+* **Important** PRs marked with the “critical” label need to be tested in the backup server before being merged. For this, one of the release coordinators (with access to deploy) should checkout a new branch from develop, merge the branch from the PR into the new branch, and initiate deployment to the backup server from this branch. The PR author should give specific testing instructions for the changes (like which job to run, what the expected output is, etc) and the coordinator should verify the same. Once successfully tested, the PR should be merged into develop. This is to prevent cases like exploration migrations which can result in data corruption (as it will auto-migrate) if the migration isn’t safe. The "critical" label needs to be applied on PRs that change data validation checks, and other possibly critical changes which could affect production data.

Debugging-Docs.md

@@ -1,8 +1,11 @@
 If you're running into an issue that you have trouble solving, you might find it useful to keep a record of your debugging process so that you can easily organize your thoughts and get help from other members of the team. The format we use for this is called a "debugging doc".
 
-To get started, make a copy of [this "debugging doc" template](https://docs.google.com/document/d/1qRbvKjJ0A7NPVK8g6XJNISMx_6BuepoCL7F2eIfrGqM/edit?usp=sharing) and fill it in. If you're new to debugging, filling out as much of this template as you can is a great way to practice and improve your debugging skills.
+To get started, make a copy of [this "debugging doc" template](https://docs.google.com/document/d/1qRbvKjJ0A7NPVK8g6XJNISMx_6BuepoCL7F2eIfrGqM/edit?usp=sharing) and fill it in. If you're new to debugging, filling out as much of this template as you can is a great way to practice and improve your debugging skills. In general, we strongly recommend writing and sharing a debugging doc if you can't figure out the solution to a problem after working on it for **30 minutes**.
+
+Once you've filled out the "Background" and "Initial investigation" parts of the template, share the debugging doc in your team's group chat or the relevant issue thread, so that others can look at it in parallel. Then, continue working on the "Hypotheses Testing" section (search the Internet, narrow down the problem window, etc.) and fill out as much of it as you can.
+
+When it's not clear what to do further, please ask for help immediately on your team chat or [GitHub Discussions](https://github.com/oppia/oppia/discussions). Note that, at this stage, reviewers will reasonably expect, at minimum, at least one hypothesis to be proposed and under investigation.
 
-**Note:** In general, we strongly recommend writing and sharing a debugging doc if you can't figure out the solution to a problem after working on it for **30 minutes**.
 
 ## Benefits
 

Frequently-Asked-Questions.md

@@ -95,7 +95,7 @@ In this case, you should resolve these merge conflicts on your local machine and
 
 ### I need more help, where do I go?
 
-If you run into any problems, please read our [Developer Wiki](https://github.com/oppia/oppia/wiki), or create a post on our [GitHub Discussions](https://github.com/oppia/oppia/discussions/categories/setup-issues), or post to our [developer mailing list](https://groups.google.com/forum/?fromgroups#!forum/oppia-dev).
+If you run into any problems, please read our [Developer Wiki](https://github.com/oppia/oppia/wiki), or create a post on our [GitHub Discussions](https://github.com/oppia/oppia/discussions/categories/setup-issues).
 
 ### How to enable maintenance mode in the local server?
 

Get-help.md

@@ -4,9 +4,9 @@
   * [GitHub Discussions](#github-discussions)
   * [Google Chat or Hangouts](#google-chat-or-hangouts)
   * [GitHub](#github)
-  * [Email](#email) 
+  * [Email](#email)
 * [How to Ask Good Questions](#how-to-ask-good-questions)
-  * [General guidelines to follow](#general-guidelines-to-follow) 
+  * [General guidelines to follow](#general-guidelines-to-follow)
   * [Providing error information](#providing-error-information)
 * [Building your skills: Technical writing](#building-your-skills-technical-writing)
 * [Setup-related questions](#setup-related-questions)
@@ -45,26 +45,25 @@ You can even mention whole teams of people! For example, if you find an issue th
 
 ### Email
 
-We have several mailing lists in the form of Google Groups that you can join, but please note that these are less active than GitHub Discussions:
+We have a low-volume announcement Google Groups mailing list that you can subscribe to:
 
 * [oppia-announce](https://groups.google.com/forum/#!forum/oppia-announce) is for announcements of new releases or blog posts. It's not for asking questions though.
-* [oppia-dev](https://groups.google.com/forum/#!forum/oppia-dev) is the main mailing list for communication between developers and for technical questions. You can post to it even if you're not a member of the group. This is where you can ask questions, solicit feedback, or make developer-specific announcements (e.g. a temporary GitHub outage).
 
-You can also email your mentor with any questions. If you don't have a mentor, complete the steps on the [[wiki page for contributing code to Oppia|Contributing-code-to-Oppia]] and we'll try to assign you.
+Please note that this list is mainly for announcements. If you have technical questions, please ask them on [GitHub Discussions](https://github.com/oppia/oppia/discussions) instead.
 
 ## How to Ask Good Questions
 
-At Oppia we don’t care how silly your question is! Just ensure your question is clear, and provide us with enough information to help us resolve it faster. 
+At Oppia we don’t care how silly your question is! Just ensure your question is clear, and provide us with enough information to help us resolve it faster.
 
-### General guidelines to follow 
+### General guidelines to follow
 
 * __Be clear and concise__: Clearly articulate your question to avoid confusion and allow others to understand it easily.
 * __Provide context__: If applicable, provide relevant background information to help others understand your question and situation.
 * __Be respectful__: Maintain a respectful and courteous tone in your communication to foster a positive and inclusive community environment.
 * __Format your text for easy reading__: Organize your question using paragraphs, bullet points, and appropriate formatting to enhance readability.
 * __Proofread your message__: Take a moment to proofread your question to ensure clarity and accuracy before sending it.
 
-### Providing error information 
+### Providing error information
 
 When reporting an error, follow these steps to communicate the issue effectively: