Trac, Workflow...

[Allison Randal]

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 <will at coleda.com> 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
>>
> 
> 
>