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 > -- Jonathan "Duke" Leto [email protected] http://leto.net _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
