Prioritising & grooming issues

[craigfowler]

We've got quite a lot of open issues on GitHub. That's not necessarily a bad thing but with a large number, we might be missing some really useful ones because they've been buried.

I think it would be useful to adopt a triage, prioritisation & grooming procedure which multiple team members can get involved in.

As usual, all of this is open for discussion. All of the below is just a suggestion. Even if people were to agree and we start with it, doesn't mean we can't change later if we find it's not working for us.

Conceptually what's useful

• Transparency: Once an issue has been through this process everyone can see what's up
• Simplicity: I've seen all sorts of complex prioritisation schemes and in my experience, the more complex the scheme the more it's misused
• A continuous process: New issues are added all of the time, so a "roll-on, roll-off" process is what we're looking for
• Avoid defeating the roadmap: We have a good-looking roadmap which can guide the process. That's something worth keeping.

Suggestion: Priority labels

To help the most important issues "bubble to the top" of the list, I'd suggest three priorities. These would probably be implemented as issue labels:

• Do now - an urgent issue which needs fixing immediately. Say a critical security flaw or a bug which blocks large groups of users. We don't expect or want to have many of these.
• Do soon - the highest-value issues which we are planning on implementing in the next two or three releases.
• Do later - anything else. This is one big soup which we expect to hold the majority of our issues. Anything which would be implemented further away than the next 2 to 3 releases goes here.

Periodically, as the "do soon" list empties, we can take a slice of the most important from the "do later" list and promote them to "do soon". When planning a new release, the "do soon" list is the shortlist of what to put into the release milestone.

It's also reasonable for "do soon" issues to be demoted to "do later". Say, we find it's not as important anymore.

Suggestion: A triage & prioritisation project

GitHub kanban projects are handy for roll-on, roll-off activities. You can archive tickets in a column and add more at the beginning at any time.

If we add a project (public or private, I don't mind) then we can use it for analysing and triaging/prioritising issues. Add a section of issues to the board & work through them there, one at a time. The process is really to sanity-check the issue and assign it a priority level. The priority an issue gets would of course be influenced by the roadmap. If the issue corresponds to something on the next step of the roadmap then "do soon", if not, "do later".

We could perhaps do 20 tickets at s time on the board like that. Once a batch of 20 is prioritised, archive them from the project and add another 20 tickets (using a search for tickets which have none of the three priority labels).

Eventually we'll have every issue in the project prioritised (probably with a handful closed too). At that point we can drop in automation so that all newly created issues go to that project for triage. At that point we have our roll-on, roll-off and a continuous process that we can keep on top of.

I'd expect the kanban columns to be the really simple: Not Started / In Progress / Triaged. Then, anybody can get involved in grooming some issues at any time, just pick one up from the not started pile and move it into progress.

[sfmskywalker]

That's a great suggestion. I've been wanting a simple triage procedure, and the one you propose sounds perfect. Let's go with that and see how it goes.

[sfmskywalker]

The project should be public. I think it might be helpful for others to see what the status of their issue is (and for others who are interested in the same issue).

[sfmskywalker]

I created a new Triage project using the "Bug triage" template. It comes with a different set of columns than the ones proposed here. I think that's fine, but if not let's change it.