Short Term Trac Milestone Ticket Triage Proposal

Due to a handful of different factors, the number of tickets in unreleased milestones on Trac has become unmanageable. One of the main reasons is the following scenario. Person milestones ticket for the next release with good intentions. Ticket is not quite ready or release scope/priorities are changed, so it gets punted. New ticket is added to next milestone. Repeat.

This, in addition to the longer than expected timeline for 5.0 and the 8 4.9.x releases, has caused a snowball effect where a large number of tickets have continued to accumulate and get passed to the next upcoming milestone.

At the time of publish for this post, there are 473 open tickets in the 5.1 milestone and 55 open tickets in the 5.0.3 milestone (most of which will be punted to 5.1 before the 5.0.3 RC is packaged on January 7th).

This is confusing for contributors, making it difficult to prioritize what to work on or understand what project goals are. It also multiplies the burden on release leads. The more tickets there are, the more bug scrubs and punting decisions required.

At some point, a reset button needs to be pushed to cleanse upcoming milestones of tickets that will not realistically be completed.

Proposal

This two-step process is being proposed to prevent punting 500+ tickets to the 5.2 milestone when 5.1 is released.

Part 1

Component maintainers and ticket owners/assignees should scrub their tickets in the 5.1 milestone. When evaluating each ticket, the following factors should be weighed.

  • Is the ticket still valid? If not, close it with a note.
  • Is it a bug fix or general maintenance task?
  • Does it fit into the 9 Priorities of 2019?
  • Can it realistically be tackled in the very near term?

After evaluating the ticket, discretion should be used to move the ticket to the 5.1.1, 5.2, or Future Release milestones. If the 5.1.1 or 5.2 milestone is chosen, a ticket owner must be assigned to ensure the ticket receives the needed attention.

The ticket owner is responsible for knowing the status of the ticket and ensuring it is either ready in time for the milestoned release or punted in a timely manner if it not. This person does not have to be the only person working on the ticket, they will simply serve as the lead for that ticket.

There is also no shame in unassigning a ticket when moving to the Future Release milestone. This will make way for another contributor to take ownership.

Step 2: Bulk Edit

Once WordPress 5.1 Beta is released, all remaining tickets in the 5.1 milestone will be moved to the Future Release milestone. The only exception will be tickets that have been reopened (each of these should be evaluated more closely). This will stop the snowball effect, allowing the 5.2 milestone to remain small and focused only on the priorities determined by the release leads. Tickets can always be moved to a milestone when deemed appropriate and an owner is identified.

Long Term: Triage Team

While this plan only addresses the very short term, an effort is underway to establish a Triage Team as one of the 9 Priorities for 2019 to address the larger issue of the over 6,500 open Trac tickets. @chriscct7, @karmatosed, and myself (@desrosj) are working on a rough draft set of rules for triaging tickets as an initial proposal for the foundation of the new Triage Team. Look out for this in the coming weeks.

Feedback

Questions? Concerns? Suggestions? Please share them in the comments. This purge needs to happen, but this is not a final proposal. Feedback is welcome!