Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-444

Streamline issue workflow and add Issue edit review



    • Type: EPIC
    • Status: Closed
    • Priority: Major
    • Resolution: Canceled
    • Labels:
    • 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:


      Less is More (& simpler is better)

      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.

      Transitions from one Disposition to another

      From a user perspective the available transitions are:

      But when 'edited' flags are taken into account, it becomes

      Getting to Unacknowledged

      • 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"

      Edit combinations

      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.


      Review interface

      • 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 bare-bones option allows the user to simply acknowledge that he has seen the change. Any reversion must be handled manually


      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.

      Quality Gate and Metric

      • 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.

      Technical Debt

      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.


        1. Selection_202.png
          21 kB
        2. Selection_203.png
          8 kB
        3. Selection_204.png
          35 kB
        4. Selection_211.png
          127 kB
        5. Selection_212.png
          110 kB

          Issue Links



              Unassigned Unassigned
              ann.campbell.2 Ann Campbell
              1 Vote for this issue
              7 Start watching this issue