On 26 Jun., 10:54, Jani Tiainen <[EMAIL PROTECTED]> wrote: > If we have enhancement states like: > > 'new', 'accepted', 'rejected' and 'implemented' > > And bug states like: > 'new', 'accepted', 'invalid', 'testing', 'fixed' > > There is not much common... So it would lead to one more factor: You > need to be able to restrict type to change depending on current state. >
There is no need to split bugs and enhancements (it's artificial anyway). Ticket type shall remain changeable. However, the present workflow/state machine is too simple, at least for professional use. 1. The Change Control Board (CCB) is missing (managers, core developers). Usually in 'New', you assign to somebody to 'Investigate'. By this it is also clear, which tickets are totally unhandled and which ones have at least a responsible developer. After Investigation (make proposal on what and how to do, effort, prio), wait for political decision 'CCB'. If accepted the ticket becomes a 'ToDo', with certain priority, and mile stone / delivery date. 'Reject' otherwise. 2. Every change needs to be tested, be a bug, a feature, a not code related thing or plain docu, so after ToDo you always get a 'Test', After 'Test' goes to 'QA', to check for process adherence. Then you get to 'Closed'. Test or QA failing goes back to ToDo or even earlier. 3. Optionally you might want to separate the change and it's integration. Maybe not in a company, but for open source I think it would be nice. 4. 'Reject' is not final. Give the owner a chance to 'Reopen' (similar to 'New'). At my last customer had a lot of upset test engineers, because 'Reject' was not told them and often done in disagreement. If owner agrees or after time limit, nobody opposes, 'Reject' becomes 'Closed' as well. 5. Of course now we have some more states: New, Investigate, CCB, ToDo, Test, QA, Closed, Reject, Reopen; optionally Integrate 6. Usually certain roles within a project have rights for certain state transitions only. Esp. CCB and QA are often protected, to ensure integrity and quality. The shortcomings of too few states are imho observable on t.e.o already. If there is interest from the core developers, I am willing to make some more formal proposal or support in some other way. Michael --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
