Draft new trac methodology

[seanh]

We want a new way of working with trac tickets and milestones etc:

• We will have a single queue of tickets, ordered by priority, that we all work on

• Tickets only get into the queue after triaging (which the devs do at regular intervals), so we and others can use new trac tickets as a dumping ground for any and all CKAN bugs and ideas without messing up the priority queue. Therefore the priority queue needs to be a special CKAN milestone or something. The devs need to regularly go through the inbox of untriaged tickets and triage them all, moving them all out of the inbox.

• Will we also assign tickets from the priority queue to individual devs in sprint planning meetings like we currently do?

[aron.carroll]

It would be great to use something like ​http://trac-hacks.org/wiki/SimpleTicketPlugin to remove most of the options when creating a ticket.

Suggestions to remove theme, repository, component and type unless they're actually useful.

[shevski]

Where do new tickets go to await triaging? Is priority set by whoever creates the ticket? Does this get revised? Will we have a field for dev time estimate or where will this go?