[ckan-dev] How we use trac

Wed May 30 12:59:22 UTC 2012

You need at least one space before the bullet points to have it
considered as a list

http://trac.ckan.org/wiki/WikiFormatting

On 30 May 2012 13:43, Toby Dacre <toby.okfn at gmail.com> wrote:
> Sean,
>
> Is there anyway to get trac to be nicer with it's markup as I keep adding
> stuff like
>
> * foo
> * bar
>
> and ending up with
>
> * foo * bar
>
> not a deal breaker but would be great if they have a plugin
>
>
> On 30 May 2012 12:09, David Raznick <kindly at gmail.com> wrote:
>>
>> 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
>> >
>>
>> _______________________________________________
>> 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
>