Trac milestone improvement ideas

I’ve been reviewing how we manage trac tickets to try to improve how we manage and prioritise feature requests and suggestions. We have many great ideas in our Future Release milestone, but all too-often that’s become the place where great ideas go to die. At time of writing, the milestone contains nearly 700 tickets, and not even I know what’s good in there, or even what was once good but now redundant.

Our current workflow is: new ticket -> [Awaiting Review] -> [Under Consideration] -> [Future Release] or [Release Milestone] or closed ticket.

“Under Consideration” is where new suggestions live while we evaluate them and gather further feedback and comment. This is a relatively recent addition in the last couple of years, and it’s helped seperate tickets we haven’t looked at yet (“Awaiting Review”) to those we are looking at.

I propose we should try tweaking how we approach the “Future Release” milestone so we gain better understanding and awareness of vetted suggestions and bug reports, which in turn will help existing and new contributors find exciting tasks to work on. Et voilà!

At the top of the pyramid, we have the two next release milestones (major and minor releases) which will work the same as they do today.
“Up Next” is a new milestone containing important or strategic tickets that our regular contributors have expressed in working on within the next two releases.
“Maybe Later” is a new milestone containing tickets that our regular contributors have decided that we have significant interest in working on, or are of a strategic importance, but less so than those in “Up Next”.
“Awaiting Contributions” is a new milestone. It contains tickets that our regular contributors have decided would be valuable enhancements for BuddyPress, but which are unlikely to be worked on by those regular contributors for the forseeable future — because they are less important than those in the other milestones.
This is pyramid-shaped on purpose. The milestones at the bottom should always contain more tickets than those at the top.

If this idea has support, we’ll have to spend alot of time reviewing the entire Future Release milestone, which is a great opportunity to close any tickets that are now irrelevant for some reason. The “Future Release” name itself would no longer be used to avoid confusion.

I would be very happy to hear your feedback on the proposed milestone changes (would they work? are they solving the right problem?).

imath 12:52 pm on June 12, 2016

Fine with me. I have a question. What happens at the end of a dev-cycle for the ticket who couldn’t be fixed in time, i’m talking about the “bump” period, how should these tickets be “milestoned” ?
- Paul Gibbs 9:43 pm on June 12, 2016
  
  Probably a mixture of “Up Next” (if the patch is nearly be done), or “Maybe Later” if it needs a lot more work. We should try to avoid moving from 2.7 to 2.8 directly (for example) because you end up with trac tickets that get punted from release to release to release and never get worked on, like https://buddypress.trac.wordpress.org/ticket/6025
netweb 12:22 am on June 13, 2016

“Maybe Later” already exists as a term within Trac, to close a ticket with a resolution of `maybelater`, not that this actually works in BP Trac but nonetheless Trac is not the simplest software to grok so having the same term for a milestone and resolution should be avoided I think.
- Paul Gibbs 10:00 am on June 13, 2016
  
  I believe BuddyPress should keep its “maybe later” tickets as a open milestone, because I think *closing* a ticket with the “maybelater” resolution is a big FU to the idea and original reporter.
  
  Ours would be, to repeat myself:
  
  “Maybe Later” is a new milestone containing tickets that our regular contributors have decided that we have significant interest in working on, or are of a strategic importance, but less so than those in “Up Next”.
  
  We can get the Trac configured to remove the maybelater resolution (it doesn’t work because that isn’t set up as a Resolution in the admin — it must be hard-coded in the front-end template, though).
  
  I am more than happy to hear alternate name suggestions.
Boone B Gorges 3:40 pm on June 13, 2016
Thanks for the work in thinking through this, Paul. My overarching thoughts: (a) Our current system is not great, so we should definitely look for ways to improve it. (b) At the same time, we should try not to overcomplicate things.

A few specific thoughts and questions –
- The “Under Consideration” milestone has never been completely clear to me, and I’m afraid it becomes less clear after these proposed changes. It seems to me that if there are more “accepted” milestones – which is what you’re proposing – then there isn’t much purpose to having a holding area for tickets under consideration. Either it goes in a milestone, or it is rejected. If we are keeping Under Consideration, which feels like an interstitial status to me, we should come up with some rules about its use, and about how the milestone ought to be reviewed. Should there be a UC-specific report, with a goal that contributors review tickets there with a certain frequency? Presumably, anything there is awaiting feedback from another contributor – should tickets be assigned for review to a specific person?
- Up Next seems a bit nebulous to me. What’s truly “up next” are those items slated for the next major release or two. Why would something be in Up Next rather than one of the next two specific releases? If there’s not enough commitment to put it in a specific milestone, it seems like that means it’s either “awaiting contributions” from someone, or something that will be worked on “maybe later”.
- Maybe Later as a milestone, rather than a resolution, suggests that we’re happy having tickets open for an arbitrary amount of time. This is basically what we’ve always done: if something seems like a nice idea, we leave the ticket in FR. IMHO, this has not served us well, as it results in our having many hundreds of never-touched tickets. (It’s possible that I’m getting too hung up on the name, as suggested in the discussion above.)
I would hope that the elimination of FR in favor of something like this schema will result in a large number of tickets being closed.

Most of these points are nitpicks, or points for discussion. I’m in favor of experimentation with various workflows.
- Paul Gibbs 8:12 pm on June 14, 2016
  
  What I like is the idea of us storing good ideas for BuddyPress that we ourselves can’t commit to building for the forseeable future. So, yes, this could mean leaving tickets open for months/years. As you say, we already do this, and we have hundreds of such “dead” tickets.
  
  I might be reading too strongly, but are you suggesting we think about closing tickets that we don’t intend to work on in the next year or two?
  - Boone B Gorges 4:59 am on June 15, 2016
    
    Yes, I was suggesting we think about it. I think there are multiple valid approaches to ticket management. On one end of the spectrum, you can be vigilant about keeping your open ticket count as low as possible, such that anything not attached to a concrete release milestone would be closed. On the other end, we never close anything that we vaguely think is a good idea. In the latter case (which is much closer to what we actually do), it’s critical to have some sort of organizational system to keep us from drowning in open tickets, which is precisely what you’re proposing here.
    
    Anyway, the general ethos of the project seems to be that we ought to keep maybe-someday tickets open, so I’m OK with that. Just wanted to raise the possibility of a more aggressive approach.
JJJ 3:49 am on June 16, 2016

I like that you liked your own post, @djpaulgibbs. ❤️
- Paul Gibbs 10:33 am on June 16, 2016
  
  I like that you like my liking of my own post
Pingback: Dev Chat Summary for June 15, 2016 | BuddyPress Dev Updates
Ray 7:18 pm on June 24, 2016

I think we do need some form of staging milestone for tickets we want to tackle in the next major release (or two).

The older “Under Consideration” milestone makes sense to me or the proposed “Up Next” would work.
- Ray 9:14 pm on July 4, 2016
  
  Can we look into implementing some of Paul’s suggestions for Trac soon? I’ve started looking into some of our Future Release tickets and I’ve seen a few that we could move out of there for possible implementation.