Re: [all candidates] Removing or limiting DD rights?
Chris Knadle <Chris.Knadle@coredump.us> writes:
> 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. :-/
While I'm all in favor of doing better when we can, have you interacted
with any large bug tracking system for which this isn't the case?
We should absolutely challenge ourselves to be the best that we can be,
and better than everyone else in the free software world when we can. But
I think we should also be realistic: things that no other large project is
doing successfully are probably Hard.
I would love for it to be realistic to tell our users that every bug
report will get an informed response, but I don't think it is, and I don't
think we should set the expectation that it's reasonable to expect this.
> 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.
Note that we already did do something about it by deprecating close in the
BTS in favor of sending a real email message to -done that is copied to
the submitter. The Debian BTS now nags the maintainer about telling the
submitter something if they use the close command.
> 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.
Submitters should really never reopen bugs unless something substantive
has changed about the bug since the maintainer closed it or unless the
submitter thinks they have information about the bug that the maintainer
doesn't have. (If the bug was closed in a new version of the package but
the new version of the package still has that bug, for example.) Just
immediately reopening it is almost always the wrong approach unless the
submitter is someone like the release team or the like who has some social
expectation of being able to override the maintainer.
It accomplishes nothing to reopen a bug when a maintainer thinks it should
be closed; they're obviously going to just close it again, and they're
usually going to consider that to be confrontational and a violation of
boundaries since they're the ones responsible for the bug state for their
packages.
The right next step is to send a reply to the bug (the maintainer still
gets it whether the bug is open or not) explaining why you disagree with
it being closed, and if that gets no response, to appeal somewhere:
debian-devel, the Technical Committee, a co-maintainer, whatever seems
appropriate.
Yes, that means users whose bugs are closed by the maintainer and who
can't persuade the maintainer to keep it open aren't going to be able to
get the bug reopened because they don't know enough about the project
structure to know who to ask, but I think that's reasonable, or at least
better than the alternatives.
> 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?
One possible option to consider when this happens is to write mail to
debian-devel (or debian-user, not sure which would be best) along the
lines of:
Hey, could folks have a look at bug #NNNNNN? I think this is a valid
bug, but the maintainer obviously disagrees. However, they've not
written me or the bug to explain why, and I don't understand the
disagreement. What am I missing?
I think that would be well-received by just about everyone.
This is just standard interpersonal tactics, but basically the goal is to
de-escalate any confrontation and try to avoid telling other people
they're wrong, and instead ask for the explanation that you're missing.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: