On Saturday, April 13, 2013 14:42:57, Russ Allbery wrote: > Chris Knadle <chris.kna...@coredump.us> writes: > > On Friday, April 12, 2013 13:52:42, Russ Allbery wrote: > >> Chris Knadle <chris.kna...@coredump.us> writes: > >>> Emailing anyone privately leads down the path of "privatization". > >>> [I've already been down this road.] As such I think it might be > >>> better to publicly CC leadership, to invite public comment rather than > >>> private conversation, because private conversation cannot address the > >>> public problem. > >> > >> I think both of you have a very strange understanding of how human > >> psychology works if you think public callouts are the best first step > >> in dealing with inappropriate behavior. I also wonder what places > >> you've worked in and what sorts of management interactions you've had > >> if you don't believe private conversation can ever address public > >> problems. > > > > Are you saying that if someone communicates abusively in the BTS > > publicly, they _shouldn't_ be publicly confronted about that at all? > > No, I'm saying that's often not a productive place to *start*, and hence I > completely disagree with this critique of "privatization." If private > communication doesn't work, some sort of public confrontation may be a > next step (in fact, it's possibly inevitable), but it's probably not a > great place to start.
Oh? But as I've seen, that's exactly what the tech-ctte does. When communication comes in that is disrespectful, the reponse (which is exactly what I'm promoting here) is this: "This is disrespectful. Stop." This does three things: 1. Points out the part of the communication that was disrespectful. 2. Takes a public stance that it should stop. 3. Preserves the dignity who was the recipient of the disrespect. An remedy attempt using private communication does none of these three things. > > Two particular bug reports I was invovled in recently had repeated > > abusive communication in them with no consequences that I could see for > > the one communicating abusively. Private communication was used to try > > to deal with that, and did not stop the abusive communication. > > That's clearly a problem, and hopefully further action was then taken, but > I think it's a rather sweeping conclusion to draw that therefore private > communication is useless because in two anecdotal cases for you it didn't > help. The above approach I've outlined would have, and later did when it was used. It's also the general recommendation given for exactly the same issue elsewhere. > > At the moment I think the above is more relevant than my prior or > > current places of employment, but I'm willing discuss that if that's > > more relevant than what happens within Debian. > > No, no, my point there is just that we're not doing something novel and > different here. Humanity has been dealing with social conflicts for quite > a while, and there is a lot of established understanding of what tends to > work and what tends not to work. If one is advocating an approach in > Debian that one would never follow at a place of employment, I think that > should at least call into question what we might be missing. Ah I see. Okay. Same thing above usually works with employers/management. > > Okay. Forgive my ignorance -- I'm not able to find definitive > > information about how this is dealt with in Debian. [Is there an > > "Employee Handbook" for Debian?] Up to now the only penalty discussed > > was expulsion AFAIK. > > Most of the sanctions Debian can take are various forms of temporary or > permanent revocation of privileges. When it comes to abusive discussion > in public places, suspending someone's ability to use that place of > discussion is an obvious possibility. I don't think you could ban a maintainer from a bug report on a package he/she is maintaining. [I realize you likely meant this for outside the BTS, but this particular thread is about ITS communication.] > If the problem is related to maintenance of a specific package, the > Technical Committee can change the maintainership of the package > (although I don't recall if that's been done). The Technical Committee deals with technical issues, and not social issues. > Most of the first rounds of intervention involve varying amounts of social > pressure, with people like the DPL or other team members of affected teams > taking the person aside privately and saying "look, no, this isn't okay." I know. If I thought that worked I wouldn't be discussing this here. -- Chris -- Chris Knadle chris.kna...@coredump.us -- 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/201304151625.49953.chris.kna...@coredump.us
