Scott Kitterman <deb...@kitterman.com> writes: > I suspect it may not be what you meant, but what I'm reading from your > response is that you think AH should be limited to telling people to be > quiet or asking DAM to show them the door?
> If that's their scope, why would anyone ever do anything other than > ignore them? What's the upside for someone who someone claims has > violated the CoC to engage with AH? It seems to me that one might as > well ignore them and see if DAM gets called in. I think we should separate how we want to organize the function from what the actions should be, since how to construct the team is complex and has a lot of possible options, and it may be more useful to start with agreeing on a goal. I think the goal should be to stop the behavior in violation of the Code of Conduct. I'm going to use aggressive personal attacks as my example, mostly since I think that's the most common. It's only an example; there are other potential issues in this space as well. Debian project business is mostly conducted on mailing lists, on IRC, and in bugs. Therefore, for aggressive personal attacks, a fast and effective anti-harassment action to stop the violation of the Code of Conduct is to warn the person doing so to stop and then temporarily ban them from that mailing list, bug, or IRC channel if they don't. It's probably immediately obvious why timeliness of response is very important here. I realize that this is already done by people other than the AH team (in this case, owner@bugs, listmaster, and IRC channel operators), but this *is* an anti-harassment function, whoever does it. It's useful to note because I don't think it's a horribly controversial one. Similarly, if there is a harassment complaint at DebConf, there are lots of examples that we can follow of other conventions with effective local anti-harassment efforts. One of the most common, if the behavior is not egregious, is to tell the person whose behavior was unwelcome to stay away from the person they were harassing for the remainder of the convention, with the understanding that if they don't they'll be removed from the premises. Do you feel like this sort of thing is "telling people to be quiet or asking DAM to show them the door?" I don't. I think it's taking immediate action to stop the violation of the Code of Conduct, which is the point. If we think we're so good at doing this that it's smooth, automatic, and predictable, and we're ready to look at much harder problems like heading off patterns of behavior or mentoring people in how to work more collaboratively, that's great, but I'm rather dubious, and that's not what I'm hearing in Sam's message or what I've seen in the project. I think we still have some work to do in making this kind of thing consistent. I think we're also lacking an escalation process for what to do if someone repeatedly crosses this line in various different project forums and repeatedly requires someone to intervene. (To be clear, I do *not* think that escalation process should be to give that person license to waste even more project time, effort, and attention.) Note that this also raises the question of how to structure and organize our response. Right now, different teams handle these problems in their own areas, with the AH team as a catch-all backstop. That has some significant advantages, but it also has a risk of inconsistency, and also a risk of burning out the AH team because they get only the hardest problems. I think one of the open questions about how to structure the AH function in Debian is whether we want to try to create more consistency or general principles, or if we're happy with the current distributed enforcement and mostly need to focus on escalation process and information sharing. (For the record, I think the listmasters and owner@bugs both do excellent jobs on the whole, although rarely I think they may err on the side of intervening too late. I personally don't use IRC, so have no idea there.) > Wouldn't it be better to try and engage members of the project that > engage in relatively minor things and try to guide their behavior in a > positive direction? Telling people they crossed a line and need to stop, and then if necessary forcing them to stop by temporarily restricting their access to the place where they're crossing the line, *is* engaging members of the project in relatively minor things and guiding their behavior. It is, in fact, by far the most *effective* way to do that. It is far more effective than trying to politely convince them to act differently, which takes considerably more time and energy and is normally read as an invitation to an argument instead of a clear statement of a boundary. > Sure, there are some things that are serious enough that no second > chances are appropriate, but not every crime deserves the death penalty. There are endless things we can and should be doing that are far short of expelling someone from the project but are still effective at putting an end to unacceptable behavior. If anything, I would like to see us concentrate our energy in finding more effective short-term ways to put a stop to behavior than to focus on mediation. The idea that there is no space between gentle coaching and mediation and some sort of destructive ultimatum is exactly the problem. This is the type of empathy that turns into paralysis. The Debian project is composed of adults who are perfectly capable of learning to control their own behavior, learning to not do things that result in someone warning or banning them temporarily from a project resource, and figuring out that a warning about their behavior is neither the end of the world nor something that they should just indignantly ignore. I don't want to be unsympathetic to people who are honestly struggling with conflicting cultural expectations, but I think we're making this way harder and way more fraught than it actually is, and are not having sufficient confidence in each other's abilities to react to conflict by modifying our behavior. Maybe we get grumbly about it, feel unfairly treated, and complain to friends; all that is a perfectly normal human reaction. As long as the behavior changes, the project can clearly draw and maintain those boundaries, and there's some escalation process leading, if we have to, up to expulsion from the project for people who absolutely refuse to modify their behavior, I think we will be in a fairly good place from an anti-harassment standpoint. Supportive mediation and coaching would be a gracious and generous gesture should someone choose to volunteer that to someone who sincerely accepted it and benefited from it, but this is a *really* high bar that practically no organization reaches, and my point in my original reply is that I don't think this should be our success criteria. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
