[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

> > 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

Reply to: