[ckan-dev] How we use trac

Wed May 30 09:29:05 UTC 2012

Sean,

Thanks, my main issue is that I think priority should be for the priority
and so awaiting merge feels wrong as a priority.  We do need to keep things
simple though.  Maybe we should add awaiting merge as a keyword or just
make a github pull request and add a link in trac and use github to see
what needs merging?  I can live with the suggested approach.

Merging new and awaiting triage seems fine to me.

Toby

On 29 May 2012 19:19, Sean Hammond <sean.hammond at okfn.org> wrote:

> 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.
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20120530/4267473d/attachment-0001.html>