This is great, Will. It's very helpful to have a break-down of the
current tickets. Agreed with the suggested workflow. A few thoughts:
Some tasklists (like "immutable strings") are discrete tasks that are
ticketable, while others (like the GC tasklist) are ongoing work lists
that don't fit as tickets. The tasklist as a whole is never closed, we
just keep rolling tasks on as needed and off as completed. The basic
idea is to recognize that wiki tasklists have become an important part
of the Parrot workflow, and "canonize" them.
Another refinement we discussed is to add a wishlist page. The rule of
thumb would be: If there's a feature you want, and you haven't discussed
it with the Parrot team, don't submit a ticket, add it to the Wishlist
wiki page.
Jonathan, agreed, whether to open a new ticket for tests is something
we'll need to evaluate on a case-by-case basis. (A simple single test,
probably not, but if it's along the lines of "develop an infrastructure
to make it possible to test X" then it's an independent task.)
Allison
Jonathan Leto wrote:
Howdy,
I am pretty much +1 to everything that was said. I am on the fence
about whether to open a new ticket for testing something. I think it
depends on the circumstances of the ticket and how hard the tests will
be to implement.
Duke
On Fri, Apr 16, 2010 at 10:13 AM, Will Coleda <[email protected]> wrote:
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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
