[ckan-dev] How we use trac

Mon Jun 25 12:44:38 UTC 2012

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

>
>
> I see what you mean, it feels like awaiting-merge should be a status so
> the workflow of statuses for a ticket would go new -> accepted ->
> assigned -> awaiting merge -> closed. I think this sort of stuff may be
> configurable in trac but I don't want to mess with it to be honest,
> prefer to stay close to the defaults.
>

Similarly, it would be useful to be able to identify which tickets are
being worked on.  Eg - we have no way of discerning "for 1.9, being worked
on this iteration" vs. "for 1.9, being worked on next iteration".  It would
give ticket reporters the ability to see if there ticket was likely to make
it into 1.9 or not.

I think this would best fit into the status workflow:

new -> accepted -> assigned -> in development [-> awaiting merge] -> closed

However, it only has value if we actually use it.  Could this end up being
something that further complicates the process?

>
> Awaiting-merge is sort of a priority of its own in a way, regardless of
> whether this ticket had high or low priority before, it now just needs
> review and merge and that should be done asap before the branch gets
> behind.
>

Personally, I'm more in favour of "awaiting merge" being a status than a
priority.

> Ok. It sounds like Nils is probably going to upgrade trac next week
> which involves a db migration, so lets wait until after that. In the
> meantime we stick to the old sprint system I think
>

Did trac get upgraded?  If so, I'm happy to look at adding this new status
(and the awaiting-merge one too) if people are if favour of either of them.

 - Ian.

>
> _______________________________________________
> 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/20120625/e42ce392/attachment.html>