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
