On Thursday 26 June 2008 11:15:28 am Michael Stratmann wrote: > 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.
Too simple? Everything you list below is doable with the provided configurable workflow and a trivial plugin to add a few permissions. (And the latter part I plan to add to core so WORKFLOW_<whatever> permissions in the workflow are automagically added. But in the mean time, a very simple plugin to provide a few extra permissions will suffice.) The time-delay part has been addressed... write a cron job. > 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. Try implementing what you want with the existing tools first. Then show us the shortcomings you run into. Eli ------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram [EMAIL PROTECTED] `------------------------------------------------- --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
