Re: [all candidates] Removing or limiting DD rights?
Chris Knadle writes ("Re: [all candidates] Removing or limiting DD rights?"):
> The #1 kind of bug reports that become problems are ones that go like this:
> - bug reporter: writes polite and detailed bug report
> - maintainer : *cloeses bug* without discussion
> (usually within the first hour of the bug's existence)
I agree that this is annoying for the submitter. I also agree that
this is not the best situation for us to be in.
But I think that the maintainer is entitled to do this. The
maintainer is in charge of setting the package's bug management
practices. In some packages it is not possible to deal "properly"
with every bug report, and it is the maintainer who has to decide how
the incoming bug stream can best be used to improve the software.
To reiterate: the purpose of bug reports is to help improve the
software. In Debian, the maintainer(s) are in charge of deciding (in
the first instance) what counts as an improvement, and which
improvements are most important. But they are also in charge of
deciding how this purpose of bug reports can best be fulfilled.
I do think that if the maintainers think it necessary to summarily
close bugs in this way it would be better if they produced a standard
text of some kind explaining this.
If the closure happens by merging with a closed report, I would hope
that the other bug would help explain the situation.
> From the point of view of the bug reporter, the message the DD has
> sent (whether intended or not) is "I'm not even going to dignify
> this with a response. *click* " It's not /only/ this rudeness
> that's the problem, though; the bug reporter has now been handed a
> puzzle of "convice the expert", where the expert needed to be
> convicned seemingly isn't willing to spend any effort in
> communicating, but the bug reporter does. This kind of thing
> therefore promotes either conflict or the bug reporter walking away
> in disgust, /either/ result of which is detrimental.
The purpose of a bug report is not to help solve the submitter's
problem. If the maintainers are already overloaded, then the bug
reporter walking away may be the best available outcome. It at least
limits the amount of further effort put into investigating a problem
when the maintainers feel that such effort would be wasted.
The remaining problem is of course the bug reporter being annoyed.
Obviously some annoyance is probably inevitable in this situation, but
it could perhaps be minimised at very low cost if the maintainer
closes the bug with a standard text explaining (and perhaps
If in this situation there is a possibility of the submitter's
experience being turned into an improvement in the software, it could
arise if the submitter
> If we could come up with a reasonable way of handling this
> particular problem, it would be greatly appreciated.
I guess you're volunteering to work to bring in the dozens or hundreds
of people into a "help desk team", that would be necessary to fully
and politely triage and investigate every bug report ? Please do go
ahead. I look forward to seeing the results!
> Do you think emailing firstname.lastname@example.org is a good way of dealing with
No. I agree that owner@bugs should deal with abuse, but what you are
complaining about isn't abuse.
> In contrast, a first response from a maintainer with an email of "I
> don't see this as a problem", but the bug report still being open,
> is about 100% better.
Not from the point of view of the maintainers. And the bug list is
primarily a resource for the maintainer.
And not from the point of view of many of the other people involved in
building Debian. Most of them will want the maintainer's view of the
bug status of a package.
Of course if a maintainer inappropriately adopts such an aggressive
approach to bug triage when it isn't necessary, you can appeal to the
Technical Committee. I doubt the TC would want to set out a decision
overruling a maintainer's workflow (and in any case it's hard to see
how such an overruling resolution could be made practical).
So if you want to do this, you will need to assemble a team to take
over the package and ask the TC to depose the maintainer(s). But
wouldn't it be better to volunteer to join the team for the package,
and help out the maintainer cooperatively ?
And finally of course if you feel an individual bug is important
enough, and the maintainer's decision clearly wrong, you can refer the
individual bug to the TC.