Epic Name:Issue Lifecycle
As a user, I need issue states to be more intuitive. Currently the combinations of statuses and resolutions are confusing. For instance, Resolved is a status and Unresolved is a Resolution. One would reasonably expect them to exist on the same continuum and they do not.
As a technical leader, I need a way to track issue edits in order to challenge them if required, I.E.
- mark as Won't Fix / False Positive
- change Severity
- change Type
And when I'm reviewing issue edits, I need to see both the changes any accompanying comments together, so that I can judge any justifications for the changes.
I also need as simple a workflow as possible, without a lot of extra flags to pay attention to.
To those ends, and under the "Less is More Banner", we will update the Issue Statuses and Resolution workflow to streamline it and allow issue edit review:
Rather than describing this in terms of changes to the existing model, it is simpler to describe the new model. Statuses and Resolutions go away. Instead, each issue has a Disposition:
- Open - Issue has been raised and needs attention. This disposition is selected by default in the Issues page
- Won't Fix - Developer has indicated that the issue is valid but not relevant
- False Positive - Developer has indicated that the issue is not valid
- Fixed - Issue has been fixed in code
- Dropped - Rule that raised the issue no longer applies, or the issue's file is no longer analyzed
Note that this abbreviated list of statuses implicitly eliminates the current Open -> Confirmed workflow, which requires that newly opened issues be manually toggled in the UI.
Each issue may have an additional "edited" flag.
When the flag is set to true, the issue has "Unacknowledged" changes. The edited flag should be exposed to the user only through the concrete fact that the issue has "Unacknowledged" changes.
From a user perspective the available transitions are:
But when 'edited' flags are taken into account, it becomes
- An issue is marked False Positive or Won't Fix
- An issue type or severity is changed
In both cases, the issue is marked as 'edited', and the edited values take effect immediately. I.e. there is no "False Positive Limbo"
Marking an issue FP or WF currently locks out the ability to change type or severity. That should continue to be the case. We will similarly lock out the ability to manually change disposition if type or severity has unacknowledged changes.
Type and severity should not block each other.
- In the code view of the issues interface, users should see an extra "Unacknowledged" item in the issue bar. For users with the "Acknowledge Edits" permission, it will be linked Clicking it will open the change review interface
- The change review interface should show an integrated audit log - events AND comments
- If the user is in an Unacknowledged search, (Unacknowledged=true), handling an edit should automatically remove the issue from the search and therefore switch the user to the next issue (with the Change Review interface open?) similar to the review workflow in StackOverflow
- Change review should generate an issue changelog entry
From here, there are two choices:
The fully-fleshed version stores previous values when type and severity are edited, and uses the "edited" flag only for disposition. It allows the user to accept or reject each change individually. (There is a corner case here to be unpacked: two sequential changes to type or severity without an intervening Acknowledgement. In this case the previous value would not be overwritten, so any final revert action would restore the field to its value before the first edit.)
If the change is rejected, the user should be prompted for a comment
We will add a new project-level permission, "Acknowledge Issue Edits". This will not be rolled into Administer Issues in order to allow a separation of concerns.
When a user with both permissions makes an Acknowledgable change (e.g. mark FP) the edit is auto-acknowledged. A simultaneous "acknowledged" entry should be written to the issue change log with the edit itself.
- Having Unacknowledged Issues should send the default quality gate into Warning status. Therefore we'll need a new Unacknowledged Issues metric, and an update to the default quality gate.
There are no changes to the current treatment of the technical debt associated with False Positive and Won't Fix issues. That is, when an issue is initially marked False Positive, it's technical debt is removed from the project sum. If the edit is rejected or the issue is reopened, the issue's technical debt is added back into the total for the project.