[ckan-dev] How we use trac

Wed May 30 12:43:54 UTC 2012

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20120530/565ee0de/attachment-0001.html>