On Wednesday, September 21, 2016 at 7:26:36 AM UTC+1, Mo wrote: > > > > Am Mittwoch, 21. September 2016 07:13:18 UTC+2 schrieb Mike Dewhirst: > >> >> Here is another "con". The above ticket requesting multiple users being >> assigned to a single ticket is not necessarily a "Good Idea". The Cc: >> list should suffice to include extra team members and the Owned >> by/developer should be one person who carries the blame when things go >> wrong. >> >> Have you looked at the configurable workflow plugin? >> > > Thanks for your recommendations. I'm interested in alternative ways.. > Yes. We have discussed alternatives to the "big ticket" approach that > would manage different roles in the same ticket. > > These alternative would be: > > * Workflow: Re-assigning to "tester, reviewer, author..." and status > progress for the ticket (to be tested, to be reviewed,...test ok, test > failed..). But one disadvantage of that is that there is no concurrent > progress on the ticket but all the process is linear. Test, Review and > documentation should work simultaneously. > > * Cc: This would be the most simple, yes. No status or role definitions > > * Separate bugs for each task: That would be the most flexible approach > and we still like to use this approach for bigger projects where test and > documentation will need their own tracking and discussion ticket. > Dependencies of sub-tasks like test and documentation will be possible with > SubTicketsPlugin (which I prefer for the subticket tree view) or > MasterTickets (the Depgraph is not that useful). We have not checked > ChildTicketsPlugin yet. > The con of that approach for smaller tickets is, that the project ticket > lists, which are long anyway, will increase by factor 3 as every single > ticket will have some review, test and documentation changes. There we were > preferring the single ticket approach with simple roles and status flags. > The Review process itself we already implemented by using the CodeReviewer > plugin on per-change basis, but anyway the ticket with 10 changes that all > passed the review has a review custom field as select of (|? : required|+ : > passed|- : failed) that is easy to check from the ticket query without > opening tickets. > > > In the meanwhile I'm checking how to use the Cc completion for custom > fields: > https://trac-hacks.org/ticket/8477#comment:19 > > Best regards, > Mo >
Speaking from experience of implementing similar processes with Trac and JIRA, I can appreciate the difficulty of configuring the tools to meet the needs of the processes that will be carried out by the team. Multiple tickets fragments the information that I often want to have aggregated in a single ticket. On the other hand, ticket fields don't suffice and probably wouldn't even if #8069 were implemented. See also discussion here: https://groups.google.com/d/msg/trac-dev/HI1mpcd5HUc/-Uz6-lULCgAJ What you describe hints at the need for multiple states for a single ticket, along with multiple workflow controls. Perhaps a "master state", along with multiple parallel spawned states that the ticket could progress through, one each for documentation, testing, etc .... That wouldn't be simple to implement, and I'd be concerned that it could lead to an overly-complex system that would be difficult for new users. I may work on #8069 in the next year, leading up to 1.4. I plan to do some work on ticket custom fields, at least adding "permission" and "max_size" attributes. - Ryan -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
