Triage improvements, take 2

bug_triage/triage_workflow.md

@@ -1,34 +1,69 @@
 # Bug Triage Overview
 
-## Basic Steps
+## Triage Workflow
 
-Make sure the issue report is in the right place and that it is filled in properly. Any issue with complex steps, or that requires specific data such as a mesh,
-should always have a minimal project attached to help testing.
+The first step of triage is to confirm that the issue is valid and filled in properly. This means that:
+* It is a bug report, for the engine, and not a:
+  - Feature proposal, belonging in [Godot Proposals](https://github.com/godotengine/godot-proposals)
+  - Online documentation issue, belonging in [Godot Docs](https://github.com/godotengine/godot-docs) (this should generally be transferred)
+  - A support question, these should be directed to other [community channels](https://godotengine.org/community/)
+* Has all the required information:
+  - The engine version tested with (with a specific version hash if not using an official release)
+  - System information in most cases
+  - Clear and detailed reproduction steps
+  - A valid MRP if the steps are not trivial, or if the issue depends on scene setup or requires data, such as animations, meshes, etc., where getting
+    the required setup to test are not trivial.
 
-If a bug is reported on the current development version (for example 4.4.beta1) as well as being reported as working in a past pre-release of the same version (for example 4.4.dev6),
-or working on the latest stable version (for example 4.3.stable) it is a regression and should be tagged with the “regression tag”,
-it should also be added to the “4.x Release Blockers” project.
-If the author of the report only reports it as happening in a pre-release it is important to check if it is a regression or not, by testing on previous versions.
+If the report is missing this information, ask for this information before proceeding. If the issue lacks critical information, or is written in a way that makes it
+difficult to classify the issue, it should be tagged with “needs work”. Otherwise you can proceed and add some basic tags to the issue and add the “needs testing” tag.
+
+Once the basic details of the issue have been verified the issue should be tagged with the appropriate tags.
+See [bug triage guidelines](https://docs.godotengine.org/en/latest/contributing/workflow/bug_triage_guidelines.html) for details on these tags.
+
+If the bug is reported on the current development version (i.e. the `master` branch, and any pre-releases such as `4.4.beta1`) it is important to verify if it also occurs
+on a past stable release. If this information is missing from the report (i.e. the author only reports having tested development versions) please either ask the author to
+test with a stable version or test the bug yourself. If it *doesn't* occur on a past release it is considered a regression and should be tagged with the “regression” label,
+and should also be added to the “4.x Release Blockers” project. See [below](#release-blocker-tracking) for details.
+
+For pre-release versions, it's critical to identify what change caused a specific bug. **All** such regressions should be bisected.
+You can ask the issue author to follow the instructions in the
+[Bisecting regressions](https://docs.godotengine.org/en/latest/contributing/workflow/bisecting_regressions.html) documentation.
+If they are not able to (or the issue is critical and should be fixed as quickly as possible), then you can look into bisecting the issue yourself.
+
+Once identified correctly it should be put on the relevant triage project(s) if appropriate. [See below](#team-triage-trackers) for a list of triage projects.
+Functional enhancements shouldn't generally be put on the trackers (i.e. new features, not enhancements to documentation). Some teams have dedicated trackers for enhancements,
+but they aren't detailed here.
 
 Try to tag an issue as specifically as possible, adding “needs testing” and “needs work” if necessary. Don't worry about misidentifying issues,
 for example classifying something as a “bug” when it's actually an issue in the documentation or a missing feature.
 Maintainers for each area will double checks reports when investigating, and will change tags as necessary.
 It's more important to get an issue tagged correctly than getting it right from the start.
 
-For pre-release versions it's critical to identify what change caused a specific bug, all such regressions should be bisected.
+### Testing an MRP
 
-Once identified correctly it should be put on the relevant triage project(s) if appropriate. [See below](#team-triage-trackers) for a list of triage projects.
-Functional enhancements shouldn't generally be put on the trackers (i.e. new features, not enhancements to documentation), some teams have dedicated trackers for enhancements,
-but they aren't detailed here.
+A valid MRP is a *minimal* project that reproduces a bug. This means that it is no larger than it needs to be, it also has to be a project, not an exported executable.
+Do _not_ run executable projects added to a bug report, they are not valid MRPs as an MRP needs to be something that can be evaluated in detail, and be tweaked if needed,
+and more importantly they are untrusted files.
 
-Try to always confirm issues while triaging. If the bug requires specific hardware, operating system, etc., that you don't have,
-please drop it in the [#bugsquad](https://chat.godotengine.org/channel/bugsquad) channel and ask for someone to test it.
+Some bugs can be hard to verify when testing different versions (for example when bisecting) due to generated data. In this case, you might need to delete the `.godot` folder
+or any user data related to the project. See [data paths](https://docs.godotengine.org/en/latest/tutorials/io/data_paths.html) for details on where these files are stored.
 
-For some of the trackers there are additional details, like category, these should usually be filled in if possible, see below for details for each tracker (including the release blocker tracker).
-If unsure what to assign leave it to the team to do. Only the fields specified below should be filled in by non-maintainers, and the status of the issue should be left in “For Team Assessment”.
+<!-- TODO? -->
 
-New issues in the tracker should then be evaluated by maintainers (this can be done during meetings for example) and moved from “For Team Assessment”, and any details should be verified,
-any incorrect information specified by the bugsquad should be fixed at this time.
+If you are unable to reproduce the bug, and the author reports using a different operating system, or using different hardware 
+(for example a different GPU manufacturer or family), please drop it in the [#bugsquad](https://chat.godotengine.org/channel/bugsquad) channel and ask for someone to test it.
+
+## Team Workflow
+
+When issues arrive in the triage projects they will have the “For Team Assessment” status. These issues should be treated as being unverified, and should be verified before
+moving the issue to another status. This can be done as part of regular team meetings, or be handled by individual maintainers processing these, as long as the assessment made
+by triagers is verified.
+
+As part of this verification, other information should be updated if needed. For example, if the issue was added to multiple trackers because it was unclear what area it
+belongs to, it should be removed from the unrelated tracker(s). This is also a good time to verify any regression severity or assign one if it is unassessed.
+
+If the report is missing information, please ask the author for more details. If the task of handling testing updated information can be handled by the bugsquad, this task
+can be handed over to them for verification: for example, testing an updated MRP provided by the author.
 
 ## Release Blocker Tracking