We had a discussion in our Slack channel recently (logs here) about how we use Trac, focusing around tickets and milestones. This morning, I was inspired to think about how we use Trac, and put some suggestions forward for ideas we could consider. I’m sharing them here to start a discussion and see what everyone else thinks.

(In the following, I’m defining “milestone” as a version number, e.g. 2.2 or 2.3. “Future Release” and “Awaiting Review” are special milestones and what follows isn’t meant to apply to them.)

Problems

Tickets are often punted from one release to the next, then to the next release, then to the next release, and so on — because no-one wants to work on them. Yet at some point, we felt they were important and are reluctant to close them.
It’s impossible to look at a milestone report and easily understand which tickets are planned for the next release (or are realistically achieveable).
Future Release is a graveyard where old tickets go and die, rather than a holding area for tickets yet to be assigned to the next milestone.

Ideas to fix this

Moving tickets to a milestone

If you move a ticket to a milestone, you are accepting the responsibility to get that task done for the next release.

You must maintain an active presence on the ticket by monitoring it for new discussion or any changes, and responding promptly.
You must keep the rest of the project up-to-date with the progress on your ticket. It’s preferred that this update is made at least every 2 weeks, in either: a dev chat meeting, a post on the bpdevel blog, or as a new comment on the ticket.

Generally, a person should not be responsible for more than 2 unfinished tickets in a milestone at any given time. Estimating time is hard, and real life is full of unexpected demands on one’s time, which are more important. 🙂

Tidy up the Future Release milestone

Let’s audit all tickets in the Future Release milestone. If a ticket has not been updated in over 1 year?, close it as “maybelater”.

Closing tickets does not mean the project will never implement the suggestions, but it will help to de-clutter our workflow and return the Future Release milestone to being a list of actionable “patchless things that are not scheduled for the next release”. I think this feels like a hard idea but is something we need to do.

We’ll need to do this on a periodic basis; maybe 2 or 3 times a year (looking for the “needs-patch” keyword).

Managing new contributions

Tickets should never be moved directly from a milestone to another (“punted”). If a ticket fails to make a release, and if we still want to implement it in a future version, then it is moved back to Future Release.

New tickets with patches (often bug fixes)

Will be moved to the Future Release milestone, with the “has-patch” keyword.
Remain in Future Release until the patch has been reviewed and is ready to commit (therefore being “sponsored” by the reviewer for inclusion in the next release).

New tickets without patches (often enhancement ideas)

Remain in Awaiting Review until the idea is fully explored. It needs to be detailed enough so it is ready for a contributer to start working on.
If the exploration takes some time, assign a new “in-review” keyword.
Once the idea is ready and it has been decided that the project would benefit from having it included, move the ticket to Future Release with the “needs-patch” keyword.

Trac reports

Most of the existing Trac reports were copied from WP’s Trac a few years ago. My feeling is that most of them aren’t useful for us. Let’s remove them all, and build the following reports to match our workflow:

All tickets waiting review
All tickets in review
Future Release tickets needing a patch
Future Release tickets with a patch
Tickets in the next major milestone
Tickets in the next major milestone, grouped by Owner (i.e. the person who set the milestone).

I just want to make clear these are my own ideas which I’m sharing for discussion. Maybe nothing will come of them, but it would be nice to try something different for the 2.3 cycle.

#trac #workflow

hnla 8:36 pm on December 31, 2014

Nicely scoped out Paul.

If a ticket has-patch, is reviewed, would not perhaps an ‘in-progress’ ( or is this the definition of ‘in-review’) keyword be applicable for something that may need iterations on the initial patch, rather than simply staying at ‘future-release’?
- Paul Gibbs 11:26 pm on December 31, 2014
  “in-review” would only apply to tickets that are in the Awaiting Review milestone (or we could make a new milestone called “In Review”; it doesn’t really matter). Perhaps “under-review” would be more accurate.
  
  The idea behind the in-review keyword is to identify tickets that need more ideation or feedback before we decide if to accept the idea. Of course, most of the time, we’ve historically been able to decide almost instantly — but imagine if someone drops off a whole set of new template parts. That would require some consideration. 🙂
  
  Writing this, I am imagining that the keyword would mostly be used for enhancement tickets, rather than bug fixes. For example, rather than just having a relatively useless “add new widget to display sprockets” in Future Release, we could:
  - First explore if we want a widget for sprockets. If we don’t, close the ticket.
  - We can think about if there’s a better way to display it than just in a widget.
  - Wireframes or mockups could be added at this stage if the widget was going to be complicated (or to help us visualise the idea).
  - Once there’s consensus and enough clarity to allow someone to proceed with development, we move the ticket to Future Release with needs-patch.
  If a ticket has-patch, is reviewed, would not perhaps an ‘in-progress’
  - If a ticket comes in with a patch for bug fix, it’ll likely be moved to Future Release and then a 2.x milestone pretty quickly.
  - If a ticket comes in with a patch for a new feature, once we’ve reviewed it and decide we want it the feature (though not necessarily the patch), it then gets moved to Future Release with has-patch or needs-patch, appropriately.
  - Tickets in Future Release with has-patch that require further iteration wouldn’t have any special keyword, like today.

Comments are closed.

BP Dev Updates

Follow development on the latest release

We had a discussion in…