On Tuesday, April 02, 2013 20:34:28, Russ Allbery wrote: > 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? Good question. I can say this: Debian's BTS is the only bug tracker in which I've ever gotten a bug quickly closed without any explanation. Bugs in Debian's BTS also tend to be "a bit more argumentative" than other bug trackers, IMHO. [This is not necessarily negative.] However these exceptions aside, bugs in the Debian BTS that I deal with get solved far more often than external bug trackers I've dealt with, and a lot of the maintainers seem like really good people who are simultaneously quite knowledgable. So if there's discussion open at all, it usually works out one way or another. Thus "the catch" seems to be getting that far in the first place for the minority of bugs where that's an issue. [And I won't get into the exceptions to the exceptions.] [...] > > 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 interesting. That sounds like an improvement in this area. If you happen to know when that was implemented, I'd be interested. June of last year I saw a bug closed (marked as done, without explanation) where I didn't see any email sent to the BTS control@ address in the bug, so I was confused as to how the bug was closed. Would emailing -done do that? > > 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. I get the feeling that most bug reporters aren't "armed" with this knowledge. /Assuming they were,/ the above seems reasonable. I think I like this enough that I'd want to include this on one of the BTS front web pages, if possible. "To be forewarned is to be forearmed." Hmm... how to title this in a nutral way... > > 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. I like this suggestion, and I think it's directly helpful. Next time this happens I'll try this. Lately I've sort of avoided [debian-devel] because some of the discussions there can be somewhat vitriolic. There's an ironic plus side to discussions there though, in that if there's any angle for an argument that's been missed, someone is likely to fill it in. The result is that you generally get to see what appear to be all sides of an issue, even if the conversation doesn't reach a consensus. (So in those cases you're "pointlessly well informed". :-P) Good suggestions. Rings true. Much apprecaited. -- Chris -- Chris Knadle Chris.Knadle@coredump.us
Attachment:
signature.asc
Description: This is a digitally signed message part.