(oops, I originally sent that mail to the apparently defunct [email protected] ... 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
