Re: [Trac] Re: Custom ticket field for users list

2016-09-26 Thread RjOllos 


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 trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Custom ticket field for users list

2016-09-20 Thread Mo 


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

-- 
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 trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

Re: [Trac] Re: Custom ticket field for users list

2016-09-20 Thread Mike Dewhirst 

On 20/09/2016 11:09 PM, Mo wrote:



Am Freitag, 1. Juli 2016 09:50:01 UTC+2 schrieb Mo:


I haven't seen a plugin for that, but it has been requested in
this ticket:

https://trac.edgewall.org/ticket/8069



Exactly the same request. Thanks. That was years ago. Any way to
push that a bit?


Generally, tracking different tasks like test and documentation
within one ticket with additional status flags will extent the
ticket size, while adding ticket (blocking) clones for additional
tasks would increase the ticket count. We discussed different pro
and cons. As every feature ticket will consist of the same
quadruple of dev/test/doc and maybe review, and usually they are
all finished very close to the project end, we tend to add flags
to the ticket for these subtasks.



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?

https://www.edgewall.org/docs/tags-trac-1.0/epydoc/trac.ticket.default_workflow.ConfigurableTicketWorkflow-class.html

If you are not already using it, that would formalize the 
dev/test/reject|accept default process steps. Being configurable you 
could insert or append a review step or anything really. For example, 
pre-doc/spec/dev/test/final-doc/reject|accept/review


It would be better IMO to have a separate ticket for the documentation 
and let that proceed via the same steps as the code. Docs can have bugs 
too. You could then have exactly the same set of steps for both tickets 
... being dev/test/reject|accept/review. Obviously you would need some 
sort of testing for the docs. Maybe a style-guide, language translations 
etc.


Mike



I was adding some ideas about such a plugin here:
https://trac.edgewall.org/ticket/2662#comment:73
I'm not capable of creating a trac plugins yet...

I found some useful part implemented here:
https://trac-hacks.org/ticket/8477
At least it is possible to have autocompletion with users on custom 
fields.

--
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 trac-users+unsubscr...@googlegroups.com 
.
To post to this group, send email to trac-users@googlegroups.com 
.

Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.


--
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 trac-users+unsubscr...@googlegroups.com.
To post to this group, send email to trac-users@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.