Michael Stratmann kirjoitti: > 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. >>
(So far this was far most interesting posting in this discussion... :) ) > 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. Well we separate "tasks", "features" and "bugs". Feature is always end user request (or maybe from marketing) that either will lead to rejecting or acceptance - which in turn creates one or more tasks. Bug is always related to end user report too. Both tasks and bugs goes at some point in QA and after that return like a boomerang or goes accepted. > 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. You can add states, but you can't restrict them very well (?) to certain roles. This is something that we miss too - for example we would like to make tickets closable only by project managers after they have agreed with customer that ticket is done. It's my intention to expand current Trac user management to support roles and bring this kind of "role" thinking to Trac. But it's something that happens somewhere beyond 0.12... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
