clone 434149 -1 submitter -1 ! retitle -1 The recipient list management is insane thanks Le dimanche 22 juillet 2007 à 10:19 -0700, Don Armstrong a écrit : > On Sun, 22 Jul 2007, Josselin Mouette wrote: > > Le dimanche 22 juillet 2007 à 07:29 -0700, Don Armstrong a écrit : > > > If you're interested in the discussion around this bug, you should > > > subscribe to it. > > > > I have already explained that I won't do it. > > Well, have fun following it otherwise. Oh, right. > > And until you do that, you just increase the workload for > > maintainers. There are 1600 bugs open on the GNOME packages; I'm not > > going to tell every bug submitter and contributor (for which there > > isn't even a sane way to make a list) to subscribe to the bug. All > > that leaves is the need to skip through the report before replying > > to any mail from the BTS. > > I'm not averse to including information in the ACK message on how to > subscribe to the bug so submitters and people who message the bug can > keep up; it's one of the things I'm going to do as I transition to > templates for the messages that the BTS sends out. I can't wait to see that. "Thanks for submitting this bug report. If you ever want to receive feedback on it, please send two other emails." Hahaha. Awesome. > > Currently bug subscribing serves as a justification to the insane > > recipient management of debbugs. "Well, you can just subscribe to > > the bug" is an excuse for everything. Sorry, but things don't work > > like that. You need to make the *default* behavior obvious. Expert > > users always find their way if it is properly documented, but novice > > users won't even try to find a documentation. > > The point is that most novice users don't care about what's going on > in a bug report until such a point when the bug is resolved; they just > want to submit a bug and get told when it's fixed. > > Users who are at a higher level should at least be capable of reading > the ack message and following instructions in it as indicated above. I don't know on what packages you are working, but on mine, things don't work like that. One users sends a report; the maintainer ask details. In the meantime, another user adds a comment to this report; the maintainer asks other details and adds the original submitter to the CC list. One of them has a relevant comment, but the other doesn't receive his mail, so the maintainer has to ask a new question to the other. That's for only two people affected. With more people, the maintainer's workload increases exponentially. How in the world is the BTS, which is configured with only one way of dealing with bugs in mind, supposed to deal with this bug profile? According to your behavior in this bug log your reply is "ignore people who don't subscribe to the bug". Sorry, that may decrease significantly the workload, but that's not how I want to deal with users. > > Sorry, but unlike you in this discussion, I expect bug reporters and > > contributors to receive the messages I send. Otherwise, I can as well > > read a book or watch TV, it will have the same result for them. > > If I want the bug reporter to see the message, I send it to > -submitter, otherwise I expect interested parties to have subscribed > to the bug or otherwise be keeping track of it. It's the same reason > why I don't Cc: people who post to mailing lists. Even when they are explicitly requesting it? Then you can bet you will never reach them. One of the few good things with Bugzilla is, when you add a comment, you get added to the CC list *unless you click the appropriate checkbox*. This is straightforward and absolutely obvious for users. I don't understand what could be wrong in mimicking it. > Currently if you want your message to go to the submitter, you e-mail > the bug number and -submitter; What if I want to reach the submitter and anyone who added comments? This is the most common case and it is not handled. If I add to that the fact there is no functionality for reaching submitters of merged reports, the BTS behaves merely as an email archive, not as an issue tracking tool. > I'm not particularly happy about how > -submitter works currently, but the solution that I enact is (most > likely) going to involve tighter integration with the bug subscription > system, rather than less. Good. Then, please make it opt-out than opt-in, add a -all address which includes both submitter and subscribers, and this will be fine. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=