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
> 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.Knadle@coredump.us
Reply to: