|
Hi Abou,
On Montag, 21. Juli 2014, Abou Al Montacir wrote: > > oh, wow, how do you want to deal with those? What do you do if these > > users don't follow up? > There is always a risk that a user make a mistake, but these questions > can only reduce the noise and increase the SNR on this comm channel.
You didnt answer my question at all: what do you do, when there is no feedback? This is very very often the case.
Past experiences show that these bugs accumulate and suddenly there are 50 useless bugs against base|general and then someome has to spend hours to clean those up. Which mostly means closing them, but this could have been (and usually now is) done immediatly.
Also please not that I *do* reassign bugs with a little bit of substance to the relevant packages. (Where they might rot again...)
> > Really there are quite many many of these bugs already, against > > base+general, but also against d-i (installation-reports) and many other > > packages, where users file "bug reports" which are *not* bug reports > > (because they lack vital information) but just "bug notices" which are > > often quite useless.
I forgot src:linux in that list. That package also desperately needs help.
> I know this very well, just taking my personal case, but my point is not > about lack of support but rather about abrupt reaction to some bugs. It > is more about nice reaction when someone reports a bad bug and teaching > him how to improve his reporting. This can help him for next bugs he > will report. [..] > I trust you here, but my rule is try to clean my packages as much as > possible and try to explain to users the real issues. Some of my bugs I > know I'll never be able to fix, but I don't close them, I just keep them > maybe someone someday will be able to do what I can't do.
Well, you maintain 4 packages with 6 bugs in total (that's totally great), but this tells me that you cannot imagine how it is, to receive one bug per day or week. (one (or three more) per day is more the src:linux case, while base probably gets a bug per week, or less.)
> > A useless bug is a useless bug. If a submitter cannot come up with any > > useful information in the report, it is very unlikey they will be able > > to come up with that later. > Here I really disagree. User my be ignorant but never assume he is > stupid. Sometimes small hints could help.
I never said I assume users are stupid. I said what I said (and what is quoted above) ;-p
> I should admit I'm not active on those due to lack of time, and I really > appreciate the energy and devotion of all active persons (not only DDs > but also users) who helped me many times on these lists. > But still, I'm not trying to replace this help channel, I'm just trying > to extend it.
No, you are not trying to extend it. You are voicing your opinion, that's all. I totally agree that Debian should be more user friendly and developers should spend more time helping users, but I also believe in world peace and I think a 48h day would be very helpful. IOW: I think your suggestions are (partly) good/justified, but without someone actually *living up* to these suggestions, they are just hot air. Sorry.
I hope I don't sound to frustrated/harsh here, but the reality is very very few people (thank you!) have regularily triaged those bugs (some help occasionally and I'm very thankful for that too), and it's mostly me caring about keeping bugs.debian.org/base|general sane. So surely everybody is welcome to make suggestions, but don't expect me to listen much, unless you are also planning to get involved in the work.
That said, there will be an event at DebConf14, called "Some Debian QA bits" where I'll be happy to discuss this (and probably change my mind and/or actions) and where I will (at least) listen to people not willing to do the work, but merely giving suggestions.
And, please trust me, I hate to frustrate users too and I try to avoid this. And (but?) I actually don't think closing a bug as "invalidate" has to be frustrating, as this helps developers to focus and thus help the users in the long run. This can be conveyed and I usually try to too.
cheers, Holger, mostly "maintaining" these bugs alone since 2009. There once was a team... |
Attachment:
signature.asc
Description: This is a digitally signed message part.