workflow branch and default workflow
Christian Boos
trac...@lists.edgewall.com ... sorry if this reappears later on)
Hello again,
I've seen that in the workflow branch, the "assigned" state has been
renamed to "accepted", as discussed in
http://trac.edgewall.org/ticket/1689#comment:6 (the "accept -> accepted"
transition being more logical than the "accept -> assigned" one).
So that's good, but it leaves open the fuzziness about what
"accept/accepted" really means, see
http://trac.edgewall.org/ticket/2045#comment:17.
I think it's a very idiomatic convention that "accepted" should actually
mean "I've started to work on the ticket". I'd rather see a more
explicit transition and state for this.
This is somehow related to the main problem I see with the default
workflow in Trac (or with the ticket system in general), already
outlined in the various triaging discussions: how to tell if a ticket
has already been screened and will be processed upon? Our current
workaround of having no milestone set for processing new tickets is
/only/ a workaround for something that should really be part of the
workflow.
A new ticket should mean 'new' and therefore that state could be used to
unambiguously look for tickets that have not yet been triaged.
A related problem is the difficulty to see if someone is really taking
care of a ticket or not, even when the milestone is set. Whenever
there's an owner associated to a given component, the tickets associated
to this component will get an owner by default, even if, in effect,
there's no active maintainer for the corresponding component. Even if
there's an active maintainer, this doesn't necessarily mean that he
wants to take care of each and every ticket associated to this component.
One way to fix the second issue would be to change the meaning of
'accepted' to /really/ mean "accepted", and add a specific 'start'
action leading to a 'started' state, which would again unambiguously
mean that work has "started".
This leads to adding an intermediate 'assigned' state to distinguish
between 'new' and triaged tickets not yet 'accepted', as a way to solve
the first problem.
In order to compensate for the addition of the new 'assigned' and
'started' states, we could remove the 'reopened' state, as this can
arguably be replaced by 'new' (see discussion in
http://trac.edgewall.org/ticket/4749).
Therefore:
- the 'new' tickets will be the untriaged ones
- the 'assigned' tickets are the ones that are recognized as valid and
for which a developer is tentatively assigned to work on (this would be
simply the current owner). This addresses the first problem, as this
state clearly disambiguates in all opened tickets the valid ones from
the others.
- the 'accepted' tickets will be the ones for which the assignee has
acknowledged to work on. This addresses problem 2) as this clearly
disambiguates in all valid tickets those for which the assigned
developer intends to work on, from those who were assigned by someone else.
- the 'started' tickets will be the one for which the owner has
effectively started to work on (these are the formerly 'assigned' ones,
in our 0.10 terminology)
- the 'fixed' tickets will be the tickets we're done with
To summarize, currently we have (sandbox/pycon/workflow):
default_actions = {
'new':
{'leave': 'new',
'resolve': 'closed',
'reassign': 'new',
'accept': 'accepted'},
'accepted':
{'leave': 'accepted',
'resolve': 'closed',
'reassign': 'new'},
'reopened':
{'leave': 'reopened',
'resolve': 'closed',
'reassign': 'new'},
'closed':
{'leave': 'closed',
'reopen': 'reopened'},
}
and I propose that we use instead:
default_actions = {
'new':
{'leave': 'new',
'assign': 'assigned', # (1)
'accept': 'accepted', # (2)
'resolve': 'closed'},
'assigned':
{'leave': 'assigned',
'reassign': 'assigned', # (1)
'accept': 'accepted', # (2)
'start': 'started', # (3)
'resolve': 'closed'},
'accepted':
{'leave': 'accepted',
'reassign': 'assigned',
'start': 'started',
'resolve': 'closed'},
'started':
{'leave': 'started',
'cancel': 'assigned', # the work can't be considered 'started'
'reassign': 'started', # someone else takes over a
work-in-progress
'resolve': 'closed'},
'closed':
{'leave': 'closed',
'reassign': 'closed', # the ownership of the ticket is
corrected
'reopen': 'new'}, # needs to be screened again, see #4749
}
In the above, I also tried to address the problem that currently
reassigning moves the
ticket back to the 'new' state
(http://trac.edgewall.org/ticket/2942#comment:5):
(1) assigning to no one is equivalent to "un"assigning, i.e. the state
goes back to 'new'
Also, assigning to oneself imply acceptance of the ticket (#2045), i.e.
the state goes directly to 'accepted'.
(2) the 'accept' action should be only present (or enabled) if the user
is the current owner (i.e "assigned to"). IOW, you couldn't 'accept' a
ticket on behalf of someone else (what would be the point?)
(3) eventually as a shortcut, useful for straightforward tasks?
The automatic setting of owner done when switching the component should
only happen for tickets in the 'new' and 'assigned' states, not for
tickets already 'accepted', 'started' or 'closed', in which case a
change of component is likely to be simply a correction for the ticket
property. In any case, this should /not/ change the state of a ticket.
(As a side note, the above default_actions can't be modeled using the
[ticket-status] / [ticket-actions] way, because the result of some
ticket-action depend on the current state, so maybe this is indicative
of a limitation we should address in the workflow configuration code)
-- Christian
Eli Carter
> To summarize, currently we have (sandbox/pycon/workflow):
> and I propose that we use instead:
I think there are a couple of issues being conflated here.
1) I think we need to be careful about what we do as a default workflow; it
should by default be as simple as we can make it. I think it would be better
to have people ask to make the workflow more complex, then have people turned
off by more workflow than they need. "new" -> "accepted" -> "closed" does
not capture the difference between "I've looked at it" and "I'm working on
it", but for those just starting out with Trac, that's probably good enough.
From this perspective, the default workflow should probably be simplified
from what is currently in the branch. (Remember, Trac by default
should "[stay] out of the way.")
2) The workflow used for t.e.o needs to meet the needs of the Trac development
process. And it sounds like it would need a more advanced workflow than the
default shipped in Trac.
Now, the t.e.o workflow would probably need to be a plugin... and it may be
that we want to ship that workflow, or one much like it, as an option in
Trac. (Which would require some way to disable interface implementations by
default.) Once we start down that road, we may want to have a couple of
workflows available out of the box. (With a code-review and/or a QA state
for instance.)
> (As a side note, the above default_actions can't be modeled using the
> [ticket-status] / [ticket-actions] way, because the result of some
> ticket-action depend on the current state, so maybe this is indicative
> of a limitation we should address in the workflow configuration code)
You can work around that by having different names for the actions;
the 'reassign':'closed' action could be "fix_owner", as an example.
But again, it's something of a work-around.
However, I believe that the expected approach for something like what you
described is not to use the .ini configuration thing, but instead write a
plugin to provide that workflow, and disable the existing workflow module.
I don't like the .ini configuration, but I haven't come up with a better idea
yet.
Thoughts?
Eli
Christian Boos
> I think there are a couple of issues being conflated here.
>
Eli, what you wrote sounds reasonable to me and I mostly agree with it.
> 1) I think we need to be careful about what we do as a default workflow; it
> should by default be as simple as we can make it. I think it would be better
> to have people ask to make the workflow more complex, then have people turned
> off by more workflow than they need. "new" -> "accepted" -> "closed" does
> not capture the difference between "I've looked at it" and "I'm working on
> it", but for those just starting out with Trac, that's probably good enough.
> From this perspective, the default workflow should probably be simplified
> from what is currently in the branch. (Remember, Trac by default
> should "[stay] out of the way.")
>
So that would be the "simple" workflow. This could effectively be the
one selected by default.
> 2) The workflow used for t.e.o needs to meet the needs of the Trac development
> process. And it sounds like it would need a more advanced workflow than the
> default shipped in Trac.
>
> Now, the t.e.o workflow would probably need to be a plugin... and it may be
> that we want to ship that workflow, or one much like it, as an option in
> Trac. (Which would require some way to disable interface implementations by
> default.) Once we start down that road, we may want to have a couple of
> workflows available out of the box. (With a code-review and/or a QA state
> for instance.)
>
The "opensource" workflow would be the one I proposed, which I think is
quite suited not only for t.e.o but in general for a distributed team of
developers, where the work units have to be dispatched and coordinated
effectively:
'assigned' : the ticket is validated and tentatively dispatched
'accepted' : someone effectively accepts to take care of the issue,
otherwise it's still open for adoption
'started' : actual progress have been made on the issue (our current
'assigned' state)
Note that this 'started' state could be advantageously replaced by a
"progress" property, a la FlySpray (#1084).
The "enterprise" would be the one frequently asked for, with the fixed
-> verified -> closed sequence, in addition to what's already provided
by the "opensource" workflow.
It should be straightforward to pick one of these. I've to look at the
code in more details to see if those 3 workflows could be implemented by
the DefaultTicketActionController, in which case switching between these
different workflows would be a matter of describing the adequate
workflow graph in the trac.ini (see below), or if 3 separate action
controllers would be needed (in which case, we probably need an
ExtensionOption on the ITicketActionController interface).
>> (As a side note, the above default_actions can't be modeled using the
>> [ticket-status] / [ticket-actions] way, because the result of some
>> ticket-action depend on the current state, so maybe this is indicative
>> of a limitation we should address in the workflow configuration code)
>>
> ...
>
> I don't like the .ini configuration, but I haven't come up with a better idea
> yet.
>
> Thoughts?
>
We could perhaps have one section for describing the whole graph, with
entries like:
# oldstate--action = newstate
So the "simple" workflow could be described that way:
[ticket-workflow]
new--leave = new
new--resolve = closed
new--reassign = new
new--accept = accepted
accepted--leave = accepted
accepted--resolve = closed
accepted--reassign = new
closed--leave = closed
closed--reassign = closed
closed--reopen = new
(as usual in the above, the word "accept" means just what you choose it
to mean, neither more nor less :-) )
-- Christian