[haiku-development] Re: Altering Trac's ticket workflow
- From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 22 Dec 2009 19:55:37 +0100
Hi,
2009/12/18 Ingo Weinhold <ingo_weinhold@xxxxxx>:
>
> On 2009-12-18 at 09:44:46 [+0100], Niels Reedijk <niels.reedijk@xxxxxxxxx>
> wrote:
>> Okay, trying to finish this thread.
>>
>> 1. Is it clear how this Trac 0.11 workflow differs from the workflow
>> we currently have?
>>
>> In short: this workflow allows us to identify 'untriaged' bug reports
>> by adding a status called 'accepted.' Currently, in theory we can
>> currently do this by looking at the tickets with status 'new' and
>> assignee 'nobody', but some components have a default owner and that
>> means that the 'new' tickets will already have an assignee.
>>
>> To address this, a new level 'assigned' will be added, which will be
>> set when a ticket has been triaged and then redirected to an owner. It
>> is then under the responsibility of that owner to assign it to someone
>> else, or to accept it (setting the status to accepted).
>>
>> 2. What will happen to me if I am a developer?
>>
>> Nothing really. If you own a component, you will still get notified if
>> new tickets arrive in your component. If the ticket belongs to you,
>> you can 'accept' the ticket. Instead of that the status will be
>> 'assigned', it will be set to 'accepted'. There are no extra steps
>> involved, it is only the internal accounting that will change.
>>
>> So in short: this change in the workflow does not create extra steps
>> or extra overhead, it just adds a minor change in the workflow and a
>> new status. After the change is implemented, I am going to see whether
>> it is feasible to organize some sort of triaging to see whether we can
>> produce better tickets before they end up on the desk of the
>> developer.
>>
>> So, is this an acceptable change?
>
> Given how we currently use the "accepted" state (which is currently named
> "assigned" -- namely as "working on it" -- I think the only thing that will
> change by introducing the new ticket state, is that there'll be three
> states instead of two a ticket can be sitting in while waiting for being
> worked on:
>
> * new: Assigned via component owner.
> * reopened: Formerly closed.
> * assigned: Assigned via triaging.
Correct.
> IMHO, the ticket state that is actually (additionally) missing is "working
> on it", so that "accepted" could be used for what it is probably meant,
> which is accepting responsibility for the ticket without implying that the
> ticket is now being working on.
Okay, so if I understand correctly you think you need to be able to
signal that a ticket belongs in you area of expertise, but without
actually saying you are going to work on it directly (thus leaving it
open for others to chip in before you). I would say leaving a ticket
in the 'assigned' state (perhaps with a short acknowledging comment)
will allow a similar scheme without adding another state. The point of
failure will of course be that moment when a 'assigned' person does
not look at the tickets that are assigned to him (and as such does not
move them forward or accepts them).
This kind of failure can still happen when you introduce the
'working-on-it' status. Things can also remain stuck in 'assigned'.
Nonetheless, for clarity purposes it is entirely possible to introduce
the 'working-on-it' stage! I'm neutral to this point.
N>
Other related posts:
