Chris Knadle <chris.kna...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fvz8jvu3....@windlord.stanford.edu