Trac Ticket Management

[Amar Takhar]

On 2014-11-23 14:30 -0500, Gedare Bloom wrote:
> > Components themselves should be very general.  'RTEMS', 'Build', 'Testing',
> > 'BSP', 'CPU' etc.
> >
> OK, if we define some tags and scope them right, this can work. I
> don't like the idea of a free-text field though. Can tags be a
> drop-down list like the other fields? So we can define the set of
> tags? Either that, or put a link to the tag cloud or an organized tag
> list next to the keywords entry box, or similar, to give users (and
> forgetful developers) some guidance about what to put there.

Keywords/tags are usually single word, space delimited lists it's meant for a 
user to decide what applies or not.  That's what a tag cloud is.

We can modify the ticket page though to add a list of 'useful keywords' to give 
an idea of ones to use.


> Using tags should be fine.

I think we should have one for architecture.  Default it to 'all' but anything 
for a specific architecture should be set.  Users will almost always fill this 
out themselves so there is little work for us.

> We have two fields, Priority and Severity. Right now, each field has 5
> choices. I'd like to reduce these to 3 each.
> 
> Priority: High, Normal, Low.  Priority encodes urgency.
> 
> Severity: Blocker, Critical, Normal. Severity encodes deferrability.
> 
> I would rename Severity->Criticality (leverage real-time jargon!), and
> change the values to "High, Normal, Low". High means the problem must
> be fixed in the affected versions. Normal means it should be fixed,
> but probably can be delayed. Low means it can be delayed without
> debate.
> 
> The matrix of Priority x Criticality will have some nice meaning also.
> High-High corresponds to "get it done immediately", whereas Low-High
> means "get it done sometime before release", and so on.
>
> I don't think we need more than 3 levels in either category.

Whoops, I forgot we had those two fields enabled.  I'm used to having at least 
one of them disabled.  What you suggested is exactly how I would do it for both 
fields with both defaulting to 'normal'.  I would suggest to add a 'minor' for 
severity so we can let others know it is an item that can be moved trivially.


> >> Third, we should fix Version to get rid of "unknown", "HEAD", and "".
> >> Tickets must be associated with a version, default to the current
> >> release series name, e.g. right now 4.11 (but soon 5.0).
> >
> > 'unknown' is being worked on and will go away.  Removing 'HEAD' is good but we
> > need to add a note to the ticket page saying 'choose version x.y.z for
> > 'devel/master'.
> >
> Yes. The default behavior also should be to choose the current release
> series name, e.g. right now 4.11, when 4.11 is released, the default
> milestone will be 5.0.

FYI I just deleted the 'unknown' version Joel fixed those. 

I made the new default milestone 4.11.1 so any new tickets will default to 4.11 
for version and 4.11.1 for milestone.

5 is really going to be it's own beast I don't think anyone will want to wait 
for that to fix a 4.11 issue unless it requires large changes.


> As I said above, I'd prefer to do this in a way that limits the sprawl
> of tags. Also, tags appear to only work for single words, thus "RTEMS
> Source Builder" gets parsed into "RTEMS", "Source", "Builder". This
> should be addressed somewhere.

Then you take away the exact reason tags and keywords exist.  It's the user that 
decides what they are relevant to the issue they are having.  Duplicates are not 
good and we can fix them however we should not limit what can be added.

Most of our tickets are filed by the same set of people.  It's OK if RTEMS 
Source Builder because "RTEMS", "Source", "Builder"  Because if someone wants to 
find all tickets related to source they'll find it.  Same goes for RTEMS.  If 
they search for 'RTEMS Source Builder' they will find it as well.


> I see this also as an enhancement to the www component. My guess is
> most tasks can be framed as (proposed) enhancements.

Here are tasks in Buildbot:

http://trac.buildbot.net/query?status=accepted&status=assigned&status=new&status=reopened&type=task&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=version&order=priority

A task is really just a task, it is a TODO of items that need to be completed 
and nothing more.


> I still think this can be framed as either a defect or an enhancement
> to the infrastructure. The fact it is for "infrastructure" could be
> selected by the tag field? This example could be perhaps, defect in
> www component, with three tags: infrastructure, ftp, daemon

No, it's a whole entire set of tickets that is logically separated from 
everything else.


> I'm mainly looking at how to keep the interface simple, especially for
> new users. For a user, the default behavior and drop-down lists should
> be easy to understand.

The interface will still be simple.  Hardly anyone will ever touch the ticket 
type.  I've never run into a case using trac where is confusing -- that includes 
project that have over a dozen ticket types.  Anyone submitting a ticket will 
know if they're going to use any of the other types.  Anyone who doesn't know 
what to do will leave it as the default.

I'm more of a fan of trying things first and seeing what comes of it.  We can 
always remove the type, severities and other bits if they are unused or become 
burdensome.  Removing it before seeing how things go could end up removing 
features that will help us out in the long run.


Amar.