Trac: options to temporarily disable emails on tickets that affect many maintainers and commits

[mojca (Mojca Miklavec)]

I opened this to discuss options/ideas to allow "quiet" changes on tickets like #39383 or #48365/#52081.

Some solutions that come to my mind:

• having a separate field similar to descriptions that would not generate email traffic
• having a checkbox saying "don't send an email when I add these changes"
• being able to a reply with a checkbox "anyone can edit text of this reply" (people could then edit reply without generating more email traffic)
• open 100 new tickets and only display a ticket query in the master ticket (I don't like that idea too much though)
• open two tickets, one to notify developers, the other one without any subscribers to actually track the progress (ideally I would like to have the ability to include the whole description field from another ticket)

See also ​https://trac-hacks.org/wiki/QuietPlugin for a potentially useful plugin.

---

After we started automatically adding new commit messages at the end of the tickets, this will become an even bigger problem. Ticket #47197 is another example with 60 subscribers and over 200 required commits. On the other hand this might be an opportunity to add some more clever automatism. My wish would be to have one comment field with a well-defined template reserved for the "bot" and then the bot could potentially change that comment as new commits arrive.

We could have some syntax like

Closes: https://trac.macports.org/ticket/{nnnnn} for {portname}
# for partial fixes
See: https://trac.macports.org/ticket/{nnnnn} for {anotherportname}

and then the bot could track progress for us in that template without notifying all the recipients about the change.

​Citing:

I think it could be good to take the discussion of your use case over to the trac-users MailingList. I have ideas on how to solve your issue, and would be happy to commit some time to implementing a plugin (if needed), for such a big and important open source project that uses Trac ;)

If you start a thread on trac-users with your ideas on how to solve it we can start discussing potential solutions.

[larryv (Lawrence Velázquez)]

Replying to mojca@…:

• having a separate field similar to descriptions that would not generate email traffic

To be honest, changes to the description itself are nearly always cosmetic in nature (i.e., committers fixing noncommitters’ WikiFormatting errors), so I’ve never found it particularly useful to receive update emails for them.

[mojca (Mojca Miklavec)]

Good point, I didn't think of that.

(One thing that I would be slightly worried about would be spammers changing fields and adding links without anyone noticing, but ...)

[larryv (Lawrence Velázquez)]

I don’t think noncommitters can modify tickets after they’re created. Otherwise they could fix their “defect -> update” errors themselves!

[mojca (Mojca Miklavec)]

Ah, ok, I forgot about that.

But you also need to consider that even when you just fix mistakes of reports that open their first tickets, it probably has educational value for them, so that they know better how to submit a ticket next time. And they usually don't CC anyone, so not many people are affected by one reply too much :)

[raimue (Rainer Müller)]

I would suggest to track the progress in a separate wiki page instead of inside the ticket. That way, users really interested in the progress can add a watch on the wiki page, while others would not be disturbed.

We could also look if a plugin such as ​IncludeMacro would allow inclusion of this status directly into the Trac ticket description.