I'm on the -project list, so no need to CC me directly. (Fine if you do,
though.)
On Tuesday, April 02, 2013 13:53:24, Ian Jackson wrote:
> 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.
Perhaps, but we agree that there's a issue with this for the bug reporter.
Communication problem.
> 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.
I agree.
> 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.
Yes and no. For situations where the bug cause is a duplicate (which is where
this happens most often), merging the bug with the others that are still open
and handling them all together seems fine, and seems to have a built-in
"explanation" of sorts.
But sometimes I see bugs with explanations as to why they're different which
get merged by the maintainer anyway, and done without explanation within an
hour of the bug being entered. In this case what the maintainer is saying is
"looks like the same thing... *click* " but doesn't respond in any way as to
why the maintainer thinks the /cause/ is the same. I've recently had this
happen, emailed the maintainer a question of why the bug was merged and
closed, and got no response. It's hard to see how this is acceptable.
Similarly sometimes I see bugs being transferred to other packages, just to
have them transferred back, and transferred away to another package again.
i.e. repeated "deflection". [Thankfully it's been a while since I've seen
this now.]
> > 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.
... No, I don't agree with this. I understand that this reteoric helps
"explain away" the problem, but it "throws out the baby with the bath water".
If this is in fact the case, why would I bother writing a bug report in the
first place? Furthermore, what would be the purpose of the Debian Technical
Commiteee?
Obviously, there are /many/ bugs that need to be fixed, and those bugs get
opened by users (of various kinds). Admittedly, there are others that don't.
The maintainer makes most, /but not all,/ of this judgment call. [You state
this similarly in the last line of your email concerning the TC.]
> 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
> apologising).
That's a /lot/ better -- yes. Some text with an explantion and some kind of
"human connection" is best; preferably just enough so that there's no need to
play the game of "20 questions".
> 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
This sounds like the start of an interesting thought... ;)
> > 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!
Phhht. I think you forgot the sarcasm tags. ;-)
Seriously, what I'm trying to do is lower the number of cases which cause
frustration and which don't get any traction. Between the " *close* "
problem, the maintainers that are MIA without the package being orphaned,
maintainers dropping working on a particular package, and maintainers leaving
certain bugs open forever with no response, a fair number of the bugs I've
dealt with go nowhere. When I go to open a bug, I know there's a fair change
that I'm just wasting my time. :-/
But it's one thing if the maintainer is MIA, it's antother thing entirely if
the maintainer simply completely dismisses my bug with *close* . I'm not
saying that figuring out an answer to this is easy (or that it should be)...
but I am trying to figure out what can be done about it.
> > Do you think emailing owner@bugs.d.o is a good way of dealing with
> >
> > this?
>
> No. I agree that owner@bugs should deal with abuse, but what you are
> complaining about isn't abuse.
That's debatable. It's certainly dismissive, and dismissiveness is one method
that's used for abuse. All that has to happen to make this *close* thing
clearly abuse is for ping-ponging of open-close of the bug, or statements like
"Are we having fun yet? *close* " from the maintainer. The first close
without explanation is almost invariably at the start of all that.
> > 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.
Given.
Right now I'm writing as a "bug reporter advocate"; i.e. using the point of
view of someone who writes and deals with bug reports, but who doesn't have
knowledge from the maintainer's side -- to offer that perspective.
> 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 ?
Starting off with a maintainer that closes my bug report with no explanation
at all? How do I join the team, when the team refuses to communicate? Why
would I make another bigger offer my time, when the team doesn't offer theirs
even when /I/ have?
You've suggested I work cooperatively, in a sitaution where there seemingly
isn't any cooperation to be had. :-/
[I agree with the /sentiment,/ I just don't see how this suggestion
realistically fits this situation.]
> 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.
Yes. Took forever for me to find out about the TC, though. [Never knew of
the TC's existence for 14 years.]
-- Chris
--
Chris Knadle
Chris.Knadle@coredump.us
Attachment:
signature.asc
Description: This is a digitally signed message part.