On Thursday, March 28, 2013 18:35:40, Don Armstrong wrote: > On Thu, 28 Mar 2013, Chris Knadle wrote: > > As a bug reporter dealing with a misbehaving maintainer, this is > > > > what I would want: > > 1. A clear place to report the misbehavior > > firstname.lastname@example.org is an appropriate place to report abusive > behavior by anyone (maintainers, users, etc) on the BTS. Likewise, > email@example.com is an appropriate place to report abusive > behavior by anyone in messages to lists. I've never heard of (nor considered) the idea of emailing the firstname.lastname@example.org address concerning "written mistreatment" behavior I see in bugs on the BTS. What I like most about this idea follows the thought of "deal with the problem while it's small, before it gets big." [More debail on this below.] > This probably should be better documented somewhere on the website, > but as I've never had to look for it, I don't know where that would > be. Someone who has searched for it and failed may have some better > suggestions. The email@example.com address is listed on certain pages linked to from www.debian.org/bugs, but there isn't any hint that it would be appropriate to email the "Debian BTS administrators" for the case that there is "written mistreatment" occurring. Concerning where to document this, my personal choice (and this is just MHO) would be in a seperate paragraph near the bottom of http://www.debian.org/Bugs/Developer and which would have a link to the paragraph at the top of the page like other paragraphs have. [Emailing firstname.lastname@example.org isn't an "advanced" topic per se, but I looked at the other pages linked to from the main /Bugs page and the other pages didn't seem as appropriate to put this suggested paragraph into.] Now... Moray brought up a main issue but I want to clarify it: --------------------------- On Friday, March 29, 2013 20:26:17, Moray Allan wrote: > On 2013-03-28 16:35, Don Armstrong wrote: > > email@example.com is an appropriate place to report abusive > > behavior by anyone (maintainers, users, etc) on the BTS. > > But how broad a definition of abusive behaviour are you taking here? > > I would have thought of contacting firstname.lastname@example.org in respect of, > say, two people battling about a bug's status in control messages, but I > wouldn't have assumed that you would want to deal with, e.g., > unnecessarily dismissive responses to user feature requests, or > maintainers who sound ruder than they intend to users who report a bug > due to not having read the documentation. --------------------------- 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) ... where "closes bug" may be a simple closing that can be re-opened, or a more complicated closing such as merging the bug with others that are closed. 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. I thus personally consider this to be the first step into "the path of the Dark Side". If we could come up with a reasonable way of handling this particular problem, it would be greatly appreciated. Do you think emailing email@example.com is a good way of dealing with this? 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. It's still be overly dismissive and can possibly go the wrong way, but there's still an opportunity for communication and the maintainer has given at least /some/ response. Usually another polite response back can open a dialog. (Not always, but usually.) > > 2. A set of guidelines maintainers should follow > > I certainly wouldn't have a problem with adopting a set of guidelines > for interactions on the BTS, but I'd prefer to have these guidelines > discussed on -project first. [We already do have guidelines for the > mailing list, too.] Sounds good to me. > > 3. A public dialog about the misbehavior with some Debian > > > > authority along with the misbehaving maintainer. > > > > Note on (3): In the cases I've dealt with, the misbehavior was in > > public bug reports, so the discussion of the misbehavior should > > likewise be public. > > Discussion of misbehavior is usually not public. If someone reports > bad behavior, owner@ or listmaster@ typically talks to the individual > concerned, and warns them about it specifically, and informs the > reporter that their concern has been addressed. In the case where > owner@ or listmaster@ have made a decision which can be overridden by > GR (IE, banning someone from using control@ or similar), -private is > notified so DDs are aware. Right now I can tell that the main tendency is for the misbehavior to be public, but the fix to be private. There are reasons why this is bad, one of which is that the person reporting the misbehavior may not have any clue as to any consequences for the person that was repeatedly mistreating them. From the "problem handler" point of view, a statement like "the issue has been handled" sounds like it means something, but from the mistreated person's point of view the "has been handled" is a total unknown and they're left clueless, and so that doesn't close the feedback loop. Let me put it another way... the Debian Social Contract item #3 says "We will not hide problems." ... But we hide fixes? ;-) -- Chris -- Chris Knadle Chris.Knadle@coredump.us
Description: This is a digitally signed message part.