[ckan-dev] How we use trac

Wed May 30 11:09:11 UTC 2012

Hello,

This looks all fine with me.  Could you try and orchestrate the
changes, I am happy to sit down with you and do

"- 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."

which seems like the biggest chunk of work.  It would be good if we
could have access to the database for this as there will be a lot of
updates.

Thanks

David

On Wed, May 30, 2012 at 10:29 AM, Toby Dacre <toby.okfn at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>