Scott Kitterman <deb...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
