Re: Questions around Justice and Our Current CoC procedures
Scott Kitterman <debian@kitterman.com> writes:
> I think that makes sense, but I think it's really pretty much the same
> thing. The "perceived authority" that means people treat feedback from
> DAM differently is the authority to suspend or expell. Ultimately and
> unavoidably, a DAM warning comes with an undercurrent of that authority.
I agree with this to an extent, but it sounded in your previous message
like you felt that threat was quite strong, and therefore wanted a slow
and careful process before even warning someone. This is the part that
worries me. I'm worried that being too slow about warnings creates
exactly the problems that the project is trying to avoid. If everything
is formal and slow, that means we end up with much-delayed, very strong
actions on situations that have had time to fester and escalate, which
increases the chances of highly divisive membership decisions.
I want a faster and more responsive process to give people effective
warnings *before* things escalate and fester in the hope that this will
mean fewer escalations to having to take membership actions.
Yes, the fact that the DAM is also responsible for expelling developers
when necessary is the reason why they can't be ignored and therefore the
reason why in some cases the warning is effective, but it's still possible
for a warning to only be a warning. Specifically, I want a warning that
does *not* imply the sort of "three strikes and you're out" escalation
path that you referred to in your message and which is indeed common in US
employment situations. I do think there's a place in the project for a
warning from some sort of trusted authority that is not perceived as a
deferred expulsion, but is something that still clearly should not be
ignored.
Or, let me put this another way: one of the fears that I've seen expressed
around warnings is that it's a permanent record sort of thing, or it
starts a file on someone, or otherwise creates a presumption of future bad
behavior. I think this comes directly from the sort of HR warning in an
employment situation that you mention. This bothers me a lot. I think
this perception is very harmful to the project because it creates
excessive shame and anger and fear, which can be quite counterproductive
in attempting to just get someone to shift their behavior.
The ideal outcome in my mind for a warning is that the person warned
doesn't do that thing again, and then *everyone forgets it ever happened*,
at least in any formal sense. In other words, I want to extend grace and
forgiveness to people, something that HR processes very much do NOT do.
To do that, we need a warning that's just a warning, where nothing further
will be said about it if the warning is received and understood.
BTW, also on that front, I think that announcing DAM warnings to the
project is a serious mistake. I understand the thought process that went
into that decision, but I really don't agree with it. The effect is to
make someone feel attacked and shamed publicly, which directly interferes
with the goal of a warning. It's also one of the major factors in making
people feel like warnings are some sort of permanent black mark against
them, which I strongly do not want to be the case.
To be clear, it's possible what I'm asking for is something less than a
warning and to reserve warnings for essentially formal reprimand or
censure. In other words, maybe the current DAM warning concept is worth
keeping in some form, and we just need some new thing.
> Ultimately Debian would be a better place if we were more open to
> listening to each other.
I completely agree.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: