Trac, Workflow...

[Will Coleda]

After recent discussion about bugs not standing out in trac, I'd like
to make some suggestions and get some feedback:

Ticket Types:
-------------------

We currently have the following ticket types. Some of this information
can be more easily tracked via other mechanisms. I think we can get
away with these three types and ditch the rest.

*bug (289)

These are actual bugs. Features that are intended to work, code is
there, but for some reason it doesn't work.

This should probably be the default ticket type until a bug is
triaged. Our users aren't going to care about our internal workflow.

* todo (157)

These are should indicate items that are not yet implemented, but the
team agrees they should be.

* RFC (65)

This is like a todo, but it requires a discussion before it goes onto
the todo pile. These tickets probably need to be hashed out on the
mailing list, or in #parrotsketch. There's just not enough traffic on
the tickets list for these to get a community review in trac. If
there's a compelling reason for a developer in charge of a component
to reject, note it and close the ticket.

* feature (23)

Not sure what the purpose of this one is. Looking at the existing
tickets, looks like this is the same as TODO or RFC, so let's retag
them.

* cage (37)

These were meant to indicate issues with items that are not feature
related. Perhaps a coding standards issue (e.g. a refactor). This
status can go away, and can be deal with with the priority flag. These
are bugs or todos.

* patch (33)

A patch has been submitted. This category needs to go away. We already
have a patch status field, and the patch is either to fix a bug or add
a feature. These are either RFCs, todos, or bugs.

* roadmap

These are high level TODO tickets; They make more sense as
roadmap-priority TODOs, if they are worth keeping at all. (see
workflow, below).

* deprecation (24)
* experimental (5)

These were an experiment to help us track things for the support
policy. I think they're just confusing the situation now.

deprecation is a TODO with a specific time frame - It's tempting to
put the earliest possible release we can remove it from in the
milestone - but that prevents the milestone from being closed if the
ticket is incomplete; do we mind if we can't mark a milestone as
complete because of this? I think just putting it in the summary of
the ticket like we did before is sufficient, e.g. the deprecation
ticket "[TODO] Migrate non-essential PMCs to dynpmcs" should probably
be a todo ticket with a summary of "Migrate non-essential PMCs to
dynpmcs [incompatible change, anytime after 2.3]

experimental features are really RFCs that already have code in place.
I recommend making them RFCs and putting in an "experimental" keyword.

* spam (0)

We have the plugin that lets us delete the spam, I think. Let's just
delete this one..



Workflow:
---------------

Responding to some suggestions that came up:

* I don't mind having wiki pages to handle task lists, but, for
example, "immutable strings" is worthy of a one-liner RFC ticket; the
individual components of how that gets done can be tracked in the
wiki, and the ticket can point to that wiki page and the branch the
work is on. I think these one-liners can be of the same descriptive
level as the roadmap items - they are just place holders so that
someone looking at the roadmap can get an overview of what sort of
work is going on the project, and what they might be able to expect in
the next release.

* tests - I don't think it's worthwhile opening a new ticket for
testing todos. The feature isn't added / the bug isn't fixed until
there's a test; adding another ticket causes more work for the person
handing off the task for testing; trac doesn't support formal ticket
linking, so there are multiple steps involved, and the person writing
the tests has to go back through the old code anyway. Might be worth
adding a new ticket property so we can easily say "work is done but
needs tests".

-- 
Will "Coke" Coleda