New ticket system workflow
As Django has grown popular and more people have been submitting feature ideas and bug reports, we've had problems scaling our human resources to handle the extra workload. Helpful bug reports got lost in the Great Sea of Tickets, which was frustrating to both contributors and maintainers.
Fortunately, we hope to have fixed that.
As of yesterday evening, we've completely revamped our ticket workflow, along with the software we use to manage it. We spent some time discussing the issues over the past week, and yesterday Jacob installed a brand-new version of Trac, our bug-tracking software, and customized it to fit the optimized ticket workflow we came up with.
What's changed? First, if you've submitted a ticket in the past, you'll notice that the "Create New Ticket" page is much simpler. We've removed the fields that we weren't using and cleaned up the layout a bit.
Next, we changed the functionality of the existing-ticket page, adding fields such as "Needs documentation," "Has patch" and "Needs tests." These new fields are much more in-line with our ticket triage process.
From now on, every new ticket will be categorized according to these criteria by our new ticket managers (more on them in a bit), entering the workflow described on our ticket triage page. In short: a ticket comes in and a ticket manager assesses it as either "accepted," "invalid/worksforme" or "requires a design decision." If it's accepted, we'll keep track of the three essential parts of a solution -- a patch, documentation and unit tests. Once those three parts have been submitted and meet our standards, the ticket will be marked as "ready for checkin."
We've got a fancy new diagram that explains this whole process.
This new process has a multitude of advantages. Ticket submitters get much more detailed (and quicker) feedback about the status of their tickets. Committers get more helpful reports about exactly which tickets are ready to be looked at. People looking to help out with small tasks can now access useful reports -- e.g., tickets needing unit tests or tickets needing documentation -- for a clear list of where they can chip in.
The whole process is much more in line with the workflow we've adapted over the past year, and I suspect our ticket responsiveness will improve greatly.
The last, most important, piece of the puzzle, is that we now have official ticket managers, a group of volunteers who work together to manage ticket metadata and otherwise streamline the process. Although anyone can -- and is encouraged to -- help out keeping tickets organized, these folks have volunteered to take ownership of the ticket tracker in the long term. Please welcome Chris Beaven (SmileyChris), Simon Greenhill, Michael Radziej and Gary Wilson!
Back to Top