Re: Dealing with ITS abuse
On Friday, April 12, 2013 13:52:42, Russ Allbery wrote:
> Chris Knadle <Chris.Knadle@coredump.us> writes:
> > On Thursday, April 11, 2013 23:49:18, Filipus Klutiero wrote:
> >> In absolute terms, contacting owner@bugs.debian.org is not a good way
> >> of dealing with any problem, as owner@bugs.debian.org is - as indicated
> >> in https://lists.debian.org/debian-project/2011/11/msg00030.html - a
> >> private email alias, with little chance of solving the issue. If that
> >> doesn't work, you can escalate the issue to project leadership as a
> >> last resort... but you'll also hit a private email alias there.
> >
> > 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?
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. This isn't about the past
though, it's about the future -- what to do when this happens. I'm thankful
that this is rare, but it's also clear (at least to me) this can and will
happen again, so I'm trying to figure out how to handle this "correctly".
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.
> > What I really want in this "game" is a "penalty flag: unnecessary
> > roughness" called by the referee so that there can be a /measured
> > response/ to the problem. Right now Debian doesn't seem to have penalty
> > flags or even a referee, and instead the roughness has to be bad enough
> > that the linesmen step in and eject the player for all time.
>
> This is not true.
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.
> However, Debian doesn't have a habit (for all the psychological reasons I
> mention above) of creating a public wall of shame to record places where
> people have been given a "penalty flag." If you weren't involved in the
> issue, you probably didn't hear about it, and IMO that's how it should be.
I'm /not/ asking to know who got a "penalty flag" (I don't need to know) --
but I and others /do/ have a need to know if those exist and what they are.
The only reason I've been looking at past events was to /infer/ what penalties
exist due to a lack of information.
> This is a volunteer project, so there's some limit to what effective
> sanction the project has available to it, and it doesn't always work. But
> the same is true in every workplace I've been in, even though a manager in
> an employer-employee relationship has many more effective sanctions
> available.
There are all kinds of limits.
-- Chris
--
Chris Knadle
Chris.Knadle@coredump.us
Reply to: