Discussion idea for how DAM/CT/etc. could work
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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: