Re: Dealing with ITS abuse
On Saturday, April 13, 2013 14:42:57, Russ Allbery wrote:
> Chris Knadle <Chris.Knadle@coredump.us> writes:
> > On Friday, April 12, 2013 13:52:42, Russ Allbery wrote:
> >> Chris Knadle <Chris.Knadle@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
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
> > 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.