Poll: should Trac send email notifications when adding or replacing an attachment?

René J. V. Bertin rjvbertin at gmail.com
Thu Nov 3 02:58:18 PDT 2016


Mojca Miklavec wrote:


>> 1- Do you agree there is no need for (this many) notifications concerning
>> changes to attachments (= you never missed it)?
> 
> No. I have always been annoyed by the fact that some users (me
> included) uploaded an attachment and then I had to tell everyone
> explicitly that a new attachment was there, and some users (me
> included) forgot.

The only thing I've been mildly annoyed with is that you have to browse back to 
the ticket page and then post a new comment. Other bug tracker allow you to 
attach a comment to a new attachment with only some scrolling down the page 
required.


> attachment, the submitter fixes the problems, but then nobody is aware
> that those things have been changed.

But you'll notice the next time you think of looking at it; I don't think 
there's really a problem here if it concerns something either of the parties 
considers important/urgent.

>> 3- Do you agree that ideally this should be a per-user setting?
> 
> This cannot hurt, but as you said this is not up to us to implement
> and you should ask upstream.

That was the idea - if there's enough demand. A random (from upstream 
perspective) trac user filing requests about features missing on some trac 
installation might well have adverse effects so I think we need to be careful 
with that.

> The only "problem" with per-user setting is that:
...
> ready to be committed" (or anything else). And then people might end
> up with three notifications (attachment deleted, attachment added, the
> additional comment by the user) or no notification at all.

Well, you can't have everything, but I'd assume that if notifications are on by 
default, those users who bother to turn them off will know they'll have to 
monitor for silent changes themselves.
Either way, I consider it bad practice to change an attachment (or add a new 
one) without a word of explanation except if it concerns only minor changes. 
Trac (also) doesn't have a diff feature for attachments, so without explanation 
you're leaving it up to your "audience" to figure out what just changed.
So yes, I indeed get 3 emails most of the time when I change an attachment, 2 of 
which are to be trashed immediately.

> PS: Isn't that question more suitable for the development mailing
> list? Regular users that don't maintain any port might open a ticket

Yes and no (I did consider cross-posting). I'd assume that most if not all 
developers are also on the users list. Of course the direction this discussion 
is taking has no place on the users list so I'm redirecting. But originally I 
wanted to reach the broadest audience to have the best chance to know what the 
entire community thinks. But above all, it's the people who open a ticket who 
are the most likely to be unhappy with the new set-up, because they really don't 
need all those notifications. It's been happening several times now that I made a 
number of changes to one of my tickets (that never drew much feedback) and 
moments later had a wow-moment when I saw the number of notifications in my 
inbox. That got old VERY quickly when I realised all those emails just confirmed 
things I knew I had done not even minutes before.
The problem here is also that it seems risky to filter out these notifications 
automatically, but I haven't looked into that yet. Would prefer not to, of 
course.

Maybe I would find attachment notifications less annoying for the tickets I'm 
following but didn't author. IOW, maybe trac could avoid sending the notification 
to the person making the attachment change. I'm rarely really interested in a 
copy of my own prose either, in fact.
Either way, there is really no need for 2 notifications when you replace an 
attachment. In fact, I find that all the more irksome because each deletion 
notification is a reminder I can't *delete* attachments...


Clemens wrote:
> 
> Option 4: I'm glad we now have notifications for attachments. It used to be
> quite annoying that you wouldn't notice if somebody attached a patch to a
> ticket without leaving a comment.

That's a no to question 1...

> They are, however, not worded to avoid bias against the status quo.


Of course they aren't. I'm not sure they could have been, but that's why I 
pointed out the fact. The ultimate goal was mostly to get people to reply who 
would otherwise have dismissed this as another one of my crazy ideas.

>> (and I agree this isn't for us to fix though evidently someone could try and
>> submit a patch).
> 
> That someone could be you! That would be very welcome!

I guess you know me well enough that if this were written in a language I knew 
and was set up to work with I'd already have done so before even opening a 
ticket. As it is someone would have to provide guidance, and that would probably 
cost more time than figuring out the patch.

Not to open another can of worms, but just how married are we to trac? Of course 
it's never evident to migrate a web service, but has it never been considered to 
investigate other popular bug trackers (e.g. bugzilla) and possibly switch over 
by redirecting all new ticket requests to the new service?
Github also has an issue tracker, for instance. I'm not familiar enough with its 
advanced features. I couldn't say if it does attachments, but it does have 1 
rare feature I like very much: replying by email.

R



More information about the macports-dev mailing list