Custom ticket field for users list

[Mo]

Hi,

as usually many people are working on tickets simultaniously we planned to manage ticket status like...

Test:
Review:
Documentation:

...not with the workflow admin and single ticket status, but as custom fields. Those custom fields fields are of tye 'select' with values like
|? : required|+ : passed|- : failed

That means the status flags can be set independently. Later we could add restrictions that the main status can only be closed after all sub status are + or something like that.
Any idea about that first?

Next we would need to select a user for
Tester:
Reviewer:
Author:

Is there a custom ticket type for listing the users like the owner field does?

Best regards.

[RjOllos]

On Thursday, June 30, 2016 at 12:29:10 AM UTC-7, Mo wrote:

Hi,

as usually many people are working on tickets simultaniously we planned to manage ticket status like...

Test:
Review:
Documentation:

...not with the workflow admin and single ticket status, but as custom fields. Those custom fields fields are of tye 'select' with values like
|? : required|+ : passed|- : failed

That means the status flags can be set independently. Later we could add restrictions that the main status can only be closed after all sub status are + or something like that.
Any idea about that first?

TicketValidatorPlugin should be able to do that:
https://trac-hacks.org/wiki/TicketValidatorPlugin
 

Next we would need to select a user for
Tester:
Reviewer:
Author:

Is there a custom ticket type for listing the users like the owner field does?

Best regards.

I haven't seen a plugin for that, but it has been requested in this ticket:
https://trac.edgewall.org/ticket/8069

- Ryan

[Mo]

Am Freitag, 1. Juli 2016 02:26:01 UTC+2 schrieb RjOllos:

TicketValidatorPlugin should be able to do that:
https://trac-hacks.org/wiki/TicketValidatorPlugin

Ok, that could create policies for status changes based on attribute states. Thanks.

Is there a custom ticket type for listing the users like the owner field does?

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.

Best regards,
Mo

[RjOllos]

On Friday, July 1, 2016 at 12:50:01 AM UTC-7, Mo wrote:

Am Freitag, 1. Juli 2016 02:26:01 UTC+2 schrieb RjOllos:

TicketValidatorPlugin should be able to do that:
https://trac-hacks.org/wiki/TicketValidatorPlugin

Ok, that could create policies for status changes based on attribute states. Thanks.

Is there a custom ticket type for listing the users like the owner field does?

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?

I don't see any reason we wouldn't accept a patch with test coverage. It's probably not too hard to implement, and there's a patch that could be a starting point in the ticket.

[Mo]

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.

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.

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

[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

[RjOllos]

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