This is a living document that describes our current bug lifecycle process in the Open Data team(s).
When we create a bug issue, we apply the “0 - New” label, apply the label for the component (for example, “Admin UI”, “Composer Server”, "Composer UI”, "Downloads", "Language", etc.), apply a label for priority (“Priority: High”, “Priority: Medium”, or “Priority: Low”), and apply the label “Bug”. The current practice is to assign it to the current milestone.
Bug scrubbing may place the bug into a future milestone, or close it as "won't fix" by adding the label "wontfix", adding a comment saying why, and closing the issue.
The developers sometimes apply the label “1 - In Progress” when they start working on an issue. This is an individual preference. They leave the label “0 - New” label on until the issue has been resolved.
When the developer fixes an issue and submits a pull request to the repository, they remove the “0 - New” label (and the “1 - In Progress” label if they use it) and apply the label “2 - Resolved”. They add a comment to the PR like “fixes #NNNN” where NNNN is the number of the bug issue. If an issue is a determined to be a duplicate, someone will remove the "0 - New" label and apply the labels "duplicate" and "2 - Resolved".
If we decide that we will not fix an issue, then we remove any other numbered label ("0 - New", etc.), add the labels "2 - Resolved" and "wontfix", and close the bug. Classifying the resolution of a bug as "wontfix" is a judgement call, and sometimes implies that documentation will need to be provided either to the Support organization or through the "About" page. (The bug still goes through the process of being examined by QA, and in the case of "wontfix", is sometimes passed on to Product for for acceptance.)
We may also decide that an issue is not a real issue, such as when the expectation of the bug is simply wrong, or the problem was observed due to a temporary bad condition of the supporting infrastructure. In that case, we remove any other numbered label ("0 - New", etc.), add the labels "2 - Resolved" and "invalid", and close the bug. (The bug still goes through the process of being examined by QA.)
When a PR is merged into the Master branch, GitHub automatically changes the status of the issue from “Open” to “Closed” (it does this because of the comment like “fixes #NNNN”).
QA queries the system the system for issues that are “Closed” and have the labels “Bug” and “2 - Resolved”. We make sure that we have a system with the latest Master branch, and we perform the Steps to Reproduce in the issue to try to verify that the bug is fixed. If our observation is that it is fixed, then we remove the label “2 - Resolved”, add the label “3 - Done (QA’d)”, and add a comment saying that it has been observed fixed, along with screen shot or other supporting documentation of the fix observation. If our execution of the STR still results in the documented unexpected behavior, then we remove the label “2 - Resolved” and add the label “4 - Reassigned”, and ensure that the issue is assigned to the developer for further investigation. (When the someone fixed the issue, they will then remove the label "4 - Reassigned" and add "2 - Resolved".
Anyone can add the label “duplicate”, mark the issue Resolved/Closed, and mention the issue that this one duplicates. In that case, we make sure that any pertinent additional information is added into the remaining active issue.
There are issues created by an automated system that checks for errors on the backend. These also have label "bug". These issues are not addressed by this process. The system on which the error is detected is noted in the bug by adding a label (opendata.arcgis.com, opendatadev.arcgis.com, opendataqa.arcgis.com). They are entirely managed by the developer members of the team.