Enrico Zini: Deconstruction of the DAM hat
Further reading
Talk notes
Intro
- I'm not speaking for the whole of DAM
- Motivation in part is personal frustration, and need to set boundaries and negotiate expectations
- history
- approve account creation
- manage the New Member Process and nm.debian.org
- close MIA accounts
- occasional emergency termination of accounts
- handle Emeritus
- with lots of help from FrontDesk and MIA teams (big shoutout)
- we are not mediators
- we are not a community management team
- a list or IRC moderation team
- we are not responsible for vision or strategic choices about how people are expected to interact in Debian
- We shouldn't try and solve things because they need solving
- Over time, the community has grown larger and more complex, in a larger and more complex online environment
- Enforcing the Diversity Statement and the Code of Conduct
- Emergency list moderation
- we have ended up using DAM warnings to compensate for the lack of list moderation, at least twice
- contributors.debian.org (mostly only because of me, but it would be good to have its own team)
- except for rare glaring cases, patterns of behaviour / intentions / taking feedback in, are more relevant than individual incidents
- we do not set out to fix people. It is enough for us to get people to
acknowledge a problem
- if they can't acknowledge a problem they're probably out
- once a problem is acknowledged, fixing it could be their implementation detail
- then again it's not that easy to get a number of troublesome people to acknowledge problems, so we go back to the problem of deciding when enough is enough
- I got to a point where I look at DAM warnings as potential signals that DAM has ended up with the ball that everyone else in Debian dropped.
- DAM warning means we haven't gotten to a last resort situation yet, meaning that it probably shouldn't be DAM dealing with this at this point
- Everyone in the project can write a person "do you realise there's an issue here? Can you do something to stop?", and give them a chance to reflect on issues or ignore them, and build their reputation accordingly.
- People in Debian should not have to endure, completey powerless, as trolls drag painful list discussions indefinitely until all the trolled people run out of energy and leave. At the same time, people who abuse a list should expect to be suspended or banned from the list, not have their Debian membership put into question (unless it is a recurring pattern of behaviour).
- The push to grow DAM warnings as a tool, is a sign of the rest of Debian passing on their responsibilities, and DAM picking them up.
- Then in DAM we end up passing on things, too, because we also don't have the energy to face another intensive megametathread, and as we take actions for things that shouldn't quite be our responsibility, we face a higher level of controversy, and therefore demotivation.
- Also, as we take actions for things that shouldn't be our
responsibility, and work on a higher level of controversy, our
legitimacy is undermined (and understandably so)
- there's a pothole on my street that never gets filled, so at some point I go out and fill it. Then people thank me, people complain I shouldn't have, people complain I didn't fill it right, people appreciate the gesture and invite me to learn how to fix potholes better, people point me out to more potholes, and then complain that potholes don't get fixed properly on the whole street. I end up being the problem, instead of whoever had responsibility of the potholes but wasn't fixing them
- The Community Team, the Diversity Team, and individual developers, have no energy or entitlement for explaining what a healthy community looks like, and DAM is left with that responsibility in the form of accountability for their actions: to issue, say, a DAM warning for bullying, we are expected to explain what is bullying, and how that kind of behaviour constitutes bullying, in a way that is understandable by the whole project.
- Since there isn't consensus in the project about what bullying loos like, we end up having to define it in a warning, which again is a responsibility we shouldn't have, and we need to do it because we have an escalated situation at hand, but we can't do it right
- We have the Diversity Statement
- We have the Code of Conduct
- We have the DebConf Code of Conduct
- We have the Debian Mailinglist Code of Conduct
- you can't encode common sense about people behaviour in written rules: no matter how hard you try, people will find ways to cheat that
- so one can use rules as a guideline, and someone responsible for the bits
that can't go into rules.
- context matters, privilege/oppression matters, patterns matter, histor matters
- example:
- call a person out for breaking a rule
- get DARVO in response
- state that DARVO is not acceptable
- get concern trolling against margninalised people and accuse them of DARVO if they complain
- example: assume good intentions vs enabling
- example: rule lawyering and Figure skating
- this cannot be solved by GRs: I/we (DAM)/possibly also we (Debian) don't want to do GRs about evaluating people
- How to DoS discussions in Debian
- example: gender, minority groups, affirmative action, inclusion,
anything about the community team itself, anything about the
CoC, systemd, usrmerge, dam warnings, expulsions
- think of a topic. Think about sending a mail to debian-project about it. If you instinctively shiver at the thought, this is probably happening
- would you send a mail about that to -project / -devel?
- can you think of other topics?
- it is an effective way of governance as it excludes topics from public discussion
- example: gender, minority groups, affirmative action, inclusion,
anything about the community team itself, anything about the
CoC, systemd, usrmerge, dam warnings, expulsions
- A small number of people abuse all this, intentionally or not, to effectively manipulate decision making in the project.
- Instead of using the rules of the community to bring forth the issues one cares about, it costs less energy to make it unthinkable or unbearable to have a discussion on issues one doesn't want to progress. What one can't stop constructively, one can oppose destructively.
- even regularly diverting the discussion away from the original point or concern is enough to derail it without people realising you're doing it
- This is an effective strategy for a few reckless people to unilaterally direct change, in the current state of Debian, at the cost of the health and the future of the community as a whole.
- There are now a number of important issues nobody has the energy to discuss, because experience says that energy requirements to bring them to the foreground and deal with the consequences are anticipated to be disproportionate.
- This is grave, as we're talking about trolling and bullying as malicious power moves to work around the accepted decision making structures of our community.
- Solving this is out of scope for this talk, but it is urgent nevertheless, and can't be solved by expecting DAM to fix it
- It is also a small group of people who cannot pick up the responsibility of doing what the community isn't doing for itself
- I believe we need to recover the Community Team: it's been years that every time they write something in public, they get bullied by the same recurring small group of people (see governance by bullying above)
- I was just saying that we are not the emergency catch all
- When the only enforcement you have is "nuclear escalation", there's nothing you can do until it's too late, and meanwhile lots of people suffer (this was written before Russia invaded Ukraine)
- Also, when issues happen on public lists, the BTS, or on IRC, some of the perpetrators are also outside of the jurisdiction of DAM, which shows how DAM is not the tool for this
- Talking about emergency catch alls, don't they have enough to do already?
- Concentrating all responsibility on social issues on a single point creates a
scapegoat: we're blamed for any conduct issue, and we're blamed for any action
we take on conduct issues
- also, when you are a small group you are personally identified with it. Taking action on a person may mean making a new enemy, and becoming a target for harassment, retaliation, or even just the general unwarranted hostility of someone who is left with an axe to grind
- As long as responsibility is centralised, any action one takes as a response of
one micro-aggression (or one micro-aggression too many) is an overreaction.
Distributing that responsibility allows a finer granularity of actions to be
taken
- you don't call the police to tell someone they're being annoying at the pub: the people at the pub will tell you you're being annoying, and the police is called if you want to beat them up in response
- We are also a community where we have no tool to give feedback to posts, so
it still looks good to nitpick stupid details with smart-looking tranchant
one-liners, or elaborate confrontational put-downs, and one doesn't get the
feedback of "that did not help".
Compare with discussing https://salsa.debian.org/debian/grow-your-ideas/
which does have this kind of feedback
- the lack of moderation and enforcement makes the Debian community ideal for easy baiting, concern trolling, dog whistling, and related fun, and people not empowered can be so manipulated to troll those responsible
- if you're fragile in Debian, people will play cat and mouse with you. It might be social awkwardness, or people taking themselves too serious, but it can easily become bullying, and with no feedback it's hard to tell and course correct
- Since DAM and DPL are where the ball stops, everyone else in Debian can afford to let the ball drop.
- More generally, if only one group is responsible, nobody else is
- Police alone does not make a community safe: a community makes a community safe.
- DDs currently have no power to act besides complaining to DAM, or
complaining to Community Team that then can only pass complaints on to
DAM.
- you could act directly, but currently nobody has your back if the (micro-)aggression then starts extending to you, too
- From no power comes no responsibility. And yet, the safety of a community is sustainable only if it is the responsibility of every member of the community.
- don't wait for DAM as the only group who can do something
- people should be able to address issues in smaller groups, without escalation at project level
- but people don't have the tools for that
- I/we've shouldered this responsibility for far too long because nobody else was doing it, and it's time the whole Debian community gets its act together and picks up this responsibility as they should be. You don't get to not care just because there's a small number of people who is caring for you.
- distinguish DAM decisions from decisions that are more about vision and direction, and would require more representation
- DAM warnings shouldn't belong in DAM
- who is responsible for interpretation of the CoC?
- deciding what to do about controversial people shouldn't belong in DAM
- curation of the community shouldn't belong in DAM
- can't do this via GRs, it's a mess to do a GR to decide how acceptable is a specific person's behaviour, and a lot of this requires more and more frequent micro-decisions than one'd do via GRs
