[ckan-dev] How we use trac

[Sean Hammond]

Here are my thoughts on how we should use trac.ckan.org to organise the
project going forward.

TLDR: My idea is to try and keep it simple as possible:

- We'll have an inbox for new, untriaged tickets that has to be sorted
  through and emptied out regularly

- And we'll have a single queue of triaged tickets that are ready to be
  worked on, and within that queue we'll do short-term steering of the
  project by prioritising tickets and assigning them to people

- _Maybe_ also do medium-long term steering by sorting the tickets into
  goal-oriented milestones, e.g. milestones for different CKAN versions,
  milestone for the new CKAN demo site, etc. (not meaningless milestones for
  sprints/iteratons)

- I hope that if we do this well the trac timeline and (if we decide to
  use milestones) the roadmap will actually become useful reports for
  seeing where the project is headed and how fast

In detail:

1. New tickets, whether created by ckan devs or (once the spam problem
is fixed) other people, get status "new", are not assigned to anyone, and
don't belong to any milestone. So you don't have to do anything - you
just go to trac.ckan.org/newticket, type out your new ticket, and hit
'Create ticket'.

Tickets with status "new" are the dumping ground for any and all
untriaged bugs, feature requests and ideas. The CKAN devs will have to
empty out this inbox regularly by changing the statuses of the tickets
from new, either accepting, assigning or closing each ticket. (We'll
also have to go through any tickets with status "repened" at the same
time.)

2. Our "priority queue" of triaged tickets that we intend to work on is
the list of all tickets with status "accepted" or "assigned".

- Like the inbox, we'll have to garden the priority queue regularly. At
  meetings we'll look through the tickets and decide which to assign to
  who, which to reassign or unassign, close, prioritise and
  reprioritise, etc.

- The assigned ones are supposed to be the ones that a particular dev is
  currently working on or will soon be, we shouldn't leave lots of
  tickets assigned to people but not being worked on as we have now.

- Within this queue we'll give higher priorities to some tickets, this
  is how we do short-term steering of the project.

- Use the "awaiting merge" priority for code that's finished and just
  needs review. This is a high priority! We want to emphasise code
  reviews more, and once something is ready for review we want it to get
  reviewed soon.

- I don't think we need the "awaiting triage" priority, that seems the
  same as the "new" status to me.

- As well as priorities we can use keywords to group tickets of a
  particular feature, e.g. "activity_streams", "vocabularies". This is
  sometimes useful when someone wants to see how the foobar feature is
  coming along.

3. Milestones and roadmap. I think we can get quite far with just a
priority queue, and introducing multiple different milestones
complicates things, but perhaps we do need milestones as a medium-long
term way of steering the project. What do others think?

The point of milestones is that they group tickets across different
priorities, statuses etc., *the milestone has a deadline*, and all the
milestones appear in the roadmap.

I don't think we should create a milestone for each sprint/iteration, as
these aren't very meaningful and I don't think we need them, we can just
take the tickets from the top of our single well-pruned prioritised
queue.

I think we might want to create more goal-oriented milestones, e.g. a
milestone for each CKAN release showing what we intend to get into that
release, and milestones for other big goals with a date, e.g. the CKAN
demo site.

It might be particularly helpful for the release manager if we put the
tickets we want to go into 1.7.1 into a 1.7.1 milestone (and refer to
the ticket numbers in the commit messages).

If we had more meaningful milestones like this then the roadmap might be
quite useful:

http://trac.ckan.org/roadmap

I could imagine the roadmap being useful for third-party devs, clients
or CKAN client team members with some technical knowledge, to see where
the project is headed.

Milestones like "future" and "backlog" might still be useful bins for
things, but they seem like a misuse of the milestone feature, so perhaps
there is a better way (e.g. a custom status or type?)

4. Timeline. Could the trac timeline, like the roadmap, actually be
quite useful for people who need to get an overview of everything that
has been happening? (especially if we get the git commit messages
integration working):

http://trac.ckan.org/timeline

Like the roadmap, it will require some technical knowledge to read it,
but it should be possible to write ticket titles and descriptions that
are understandable to people other than the particular devs who wrote
them.

* * *

So what do we need to do with the existing tickets if we want to adopt
this approach? Unfortunately trac will need a big tidy up:

- Tickets in the current-ckan-sprint-2012-06-25 milestone should be
  removed from that milestone (which should be deleted) and their
  statuses should be set to accepted or assigned. This becomes our
  priority queue.

- We need to go through all the old sprint milestones, the ckan-v1.7
  milestone, and the tickets with status "new" and no milestone, and
  decide what to do with the status of each ticket (accept, assign,
  close) and then delete the milestones.

- Depending on whether or not we want to use goal-oriented milestones,
  perhaps we want to keep the ckan-v1.8 milestone and make a ckan-v1.7.1
  milestone, and we may want to sort the accepted and assigned tickets
  into these goal-oriented milestones.

- I guess we should leave the backlog and future milestones as they are
  and keep using them, at least for now, just because there's a lot of
  stuff in there.

- Also unassign currently assigned tickets that people aren't actually
  working on.