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 ticketticket Created for both bug reports and feature development on the bug tracker. for the next releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. 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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. 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 makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). way for another contributor to take ownership.

Step 2: Bulk Edit

Once WordPress 5.1 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 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: Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. 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!