I've been posting a lot on back and forth philosophical discussions, from which it's probably hard to extract a clear idea of what I'm arguing for. I've also gotten a few things entirely backwards, and understand a few things better than before the discussion. So in the interest of trying to make all this more concrete and constructive, here's my current mental idea of what I'd ideally want.
I'm certain this is not implementable as-is and is probably full of practical problems obvious to the folks who have been doing the work. This is intended just to make my opinion more concrete. I'm effectively asking for more intervention, earlier, but milder. That means more work, and capacity for work is one of the biggest problems. That in turn to me implies a large team so that the work can be spread. I don't like either the judicial or the employment model; I think the problem we have looks more like a moderation problem (with the understanding that it's the sort of moderation problem where moderators can kick people off entirely if necessary). I'd therefore look to how large moderation teams are structured. I think that would look something like this: * A team of at least 12 people, ideally more, whose mandate is to try to keep interpersonal interactions in Debian constructive and not abusive. Ideally, this would include the moderation functions of owner@bugs, listmaster, and IRC ops as well, so that all the project interactions are consistently covered by the same rules. * Within that team, some sort of rotating on-call system so that people only have to field problems for some fixed period of time and then can step down for a while and only look at appeals. This is very common in large moderation teams to keep people from burning out. * Whoever is on-call is empowered to warn people their behavior is crossing lines without consulting with anyone else and without some big process of public review, but such warnings are also not justification for further action and are just between the person on-call and the person they're warning (although of course the person they're warning can choose to make this public if they want to). This is "hey, that wasn't okay, I don't want to start a formal process and I would like to forget this ever happened, but I will start a formal process if I have to." * On-call is also empowered to use whatever sort of slow-down or temporary pause measures we have available: putting a list topic on slow mode, temporarily (like 24 to 48 hours) stopping someone from posting to a mailing list (other than debian-vote) or a bug, that sort of thing. Whatever non-permanent measures we can come up with to put a heated exchange on pause so that people can take a breath and hopefully de-escalate. * Anything more serious, like a formal warning akin to what we have now, stopping someone from interacting with a bug more permanently, longer restrictions on mailing list posting, or whatever we come up with, needs the approval of a three-person panel chosen from the larger group (ideally also via rotating on-call). The goal here is still to stop a bad interaction so that we can get back to being constructive, but these are things that people have more grounds to be upset about, so having the broader sanity check is useful (and if I were on-call, in the hypothetical world in which I felt like I had enough emotional energy to help, I would be very unwilling to act without having this sort of agreement). I think the panel level is also the right place to handle banning someone who isn't affiliated from the project from our mailing lists or BTS for bad behavior. * Appeals, and serious membership actions like expulsion or suspension, go to DAM as a whole. With 12 people that probably will require a vote because 12 people is too much for consensus. For expulsion it probably requires a supermajority. For expulsion we probably want to keep the appeal to the NMC. * Obviously since everyone involved is still a project delegate, the final appeal is as always to a GR. As always, my goal here is to enable people to make more decisions, faster, with less process, when the consequences are minor and reversible, and reserve the heavy process for things that are major and irreversible. One obvious problem is that we need to find at least 12 people to do a pretty thankless and stressful job. Hopefully this bounds the level of work a bit more. Another obvious problem is that we still have to figure out how to select those folks. I think the goal of this group should be to reflect the will of the project as it currently is, not how we might hope it would be. I would be very tempted to use some sort of approval voting for this: anyone can volunteer and is added if they get a 2:1 majority over the default option. But selection, and the cross-section of selection with people who are willing to do this work, is probably the hardest part of this. Anyway, I am *not* proposing that we adopt this system. I'm sure it's full of other problems I haven't seen. I'm just hoping that this makes all of my ramblings a bit more concrete and lets other people understand the sort of model I have in my head. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>