Hey folks,
The DAM team and the Anti-Harrassment team got together with the DPL
for a short sprint at my place in Cambridge over the weekend of
22nd-23rd of June. We had some frank discussions about how the teams
have been working together over the last few years, including some
retrospectives of recent events and conversation about current AH
issues. We also started discussing how we think the teams can work
together in the future to help make Debian a better, more welcoming
place. Here's a (delayed, sorry!) report of what we spoke about and
plans for future actions.
This text is based on notes taken on the weekend of the sprint; some
some of the things listed here may have been obsoleted, superseded or
changed by recent discussions.
DISCLAIMER: as you may expect, some of the discussions were about
private interactions between AH and other members of the project. Of
necessity, this report will not go into those details.
1. How do the DAM team see themselves?
======================================
DAM is the group in Debian with the final call on who is/not a DD -
they define processes for becoming a DD and how DDs become not-DDs.
DAM is the final port of call for dealing with problems. By the time
that people are reporting things to DAM, they are normally at a bad
stage. Things have already deteriorated, emotions are high and it's
difficult for people to talk sensibly. Things are normally too late to
salvaged. DAM is often seen as the "big hammer" for membership, the
judges.
To fix that, would they be happier to maybe have things presented to
them earlier? Not necessarily - the team is too small, and others
might be better at talking to people. Maybe it could work if others
are driving the discussion, but DAM do not want to be in charge of
this.
Would it help if people understood that talking to DAM is not just for
"we're going to terminate your membership"? Yes! It would also be
useful for more frontline teams in Debian to keep records about
problematic interactions and mediations. DAM could then be involved
later to review things if necessary, without having to be directly
involved in every interaction. They could then have a consistent
picture for consideration about removals or other sanctions, just like
the project collects input about people wanting to become DMs and
DDs. DAM is looking for longer-term patterns here - they don't want to
be acting after individual, one-off outbursts or mistakes that we all
make from time to time.
Counterpoint: not being involved too early also gives DAM some
independence, as they're not involved in the emotion of an ongoing
argument. Getting involved early also adds more noise and more
incoming stuff.
How burnt out are the DAMs? They could do with more fresh energy,
maybe, like most Debian teams. Is anybody looking to transition out?
Enrico got involved to help fix the NM process, but is bored/bad with
routine work. Others are similar. Routine work can lag a little from
time to time. It's helped by a regular ping from the keyring
maintainers and front desk on the 24th of each month :-) Thankfully,
the routine stuff is nice and easy, thanks to Enrico's website work!
Approving a new DD typically involves looking for 3 or 4 points in the
log of all the AM discussions, then a quick skim of mail logs. Should
we be looking for more DAM members to help? Talk to DPL separately
about this.
If something stressful comes up, that's more awkward than the routine
things. Getting people together reasonably soon can be hard, and the
process sucks a lot of energy.
DAMs can see a problem with a lack of working SSO. This is making it
difficult to get into NM at all. They want to get this fixed soon.
2. How does AH see themselves?
==============================
AH are trying to be the front line for DAM, taking load off and
handling things before they're too late. Also being the team to uphold
the CoC when needed. Overall, they're still very fuzzy on exact
responsibilities and reach, which doesn't help them or the project as
a whole. Hoping to work out separation of concerns and powers. The
team is just an email alias, with no specific delegated powers. The
email is a contact place for complaints, and also hate messages from
some people :-(
The team need to improve responsiveness, as they're not doing such a
good job keeping up.
They try to make recommendations to individuals and teams, and aim to
give feedback to people if there is problematic behaviour. They are a
reactive group rather active, which is good. Our community should be
mostly self-enforcing, we're just here to help. But we're often too
slow to respond.
The team has grown out of a range of events and initiatives, with no
delegation. Is lack of authority a good thing? Maybe - delegation can
be useful for authority, but then people can also complain that
actions are out of the scope of delegation. It might be good that AH
has no official power, as people can feel safe to talk to the team
without fear of repercussions.
It can be a problem that it's not clear to the general project what AH
is for, and how to work with them. Should people talk to AH, or DAM,
or DPL?
Is there a problem with burnout? Yes, particularly since the recent
bad cases. There's a lack of people and motivation at the moment. An
example is the regular team meeting every 2 weeks - often "homework"
is not done and people often losing track of stuff, or the meeting
itself.
We have three members in the team at the moment. There's a general
agreement that AH team must only be DDs, due to private
information/discussions. In terms of recruiting more people, there's a
worry about people maybe offering to help only during conflicts. We
need to ensure people are sensible and reliable and not just
interested on the spur of the moment. We really need to have more
people involved, to spread the load and get to the point where we can
be responsive *and* let people have downtime. People should *not* feel
pressured to stay involved if it's not fun!
3. How does Sam see the DPL role?
=================================
Sam has had much less mediation so far than expected. Checking the DPL
mail archives, he's not seeing enough mediation. Are things left to
fester too much? There are lots of longstanding issues, left for
years. 4 items on his plate at the moment:
* DebConf
* Technical consensus building
* 2 DDs he's working on complaints with (not naming them here)
He's happy to try and build consensus, facilitating agreements and
discussions.
The DPL gets lots of feedback - lots of people start here first. This
is not necessarily wrong, but it's difficult to make things scale. One
person with reasonable amounts of time can mostly manage, and it's
good to have a good overview of everything. Sam has reviewed lots of
historical discussions, and is coping with it so far. Dealing with
reimbursements is much more draining!
It's not clear how the DPL can load-shed if needed.
It's really useful that we do have good history, at least - lots of
mail archive etc.
Sam is not burned out (yet!). He's not sure about standing for another
term yet - see how it goes!
Sam says that it's been great to see the huge amounts of awesome work
and effort that happens in Debian. You get to see the sausage being
made, and in this case it is wonderful to see how much good work and
soul goes into it :-) Most people could see this too, but the DPL has
to take care of this and see how it's going. It's great for Sam to
have time from his employer to do the DPL job, and also the motivation
to go and understand stuff. Any DD could do it, but it's the DPL job.
The DPL job is lots of work, but each DPL gets to basically define
their own role and focus. Most requests are easy and reasonable, but
some of them are a struggle, particularly from people new to the
process and not sure what they're doing or why. (Similar to some AM
processes?) A future term might focus more on the financial side.
4. Review of Sam's survey results
=================================
[Not giving too much detail here, as Sam has already presented his
results separately since the sprint.]
* Feedback from 17 respondents across various kinds of involvement
with AH - mixed positive and negative feedback.
* The Code of Conduct is a problem for some people. While the project
as a whole strongly endorsed the CoC it a GR back in 2014, some
feel that we changed what it means to be part of Debian.
* Some in the project worry about "education" vs "re-education" and
the connotations of the latter with oppressive regimes. How do we
frame good answers for this?
* In terms of the CoC, some people seem genuinely upset and worried
that they can't say *anything* for fear of disagreement/humiliation
etc. We need to be compassionate about dealing with things.
* How do we cope with people when their values and Debian's clearly
are not compatible? Even more awkward if they are OK within Debian,
but publicly *not* elsewhere.
* The AH team is not trusted by everybody, maybe because it's not
responsive enough?
* The "a-h" name is not helping! Wording is hard, and will be twisted
by critics.
* Some people think the AH team does not try (enough?) to work with
people who are being "called out" for inappropriate behaviour.
* Some people are complaining about "rules" -- rules lawyering,
looking at rules as the be all and end all of appropriate behaviours.
* How do we make mediation response (etc.) quicker? Individual team
members can reply without waiting for discussion, and we should be
doing that.
* We are not trying to tear people down, and apologies are not
expected to be humiliating. The aim of AH work is about
self-awareness, not grovelling.
* There is concern about conflicts of interest in some cases. We
spoke a lot about this as a separate topic later.
* How do we spread ownership of respect and values to the whole
project? AH are not the only gatekeepers, just here to help.
* Overall, the project needs some policing to protect people, but we
need the trust of the project for that to work.
5. What is the scope of AH? How should things work?
===================================================
We brainstormed a lot of things that *could* be the realm of the AH
team:
* Reviewing reports and recommending actions to other teams
* Helping other people become better members of the Debian community,
communicating with one another more clearly
* Diversity team or AH? Diversity is trying to improve the project,
AH is about helping individuals to improve?
* Mediation?
* Building connections between people. Reach out (privately) to
people
* Making the project more welcoming
* Talking about privilege
* Explaining problems with wording / discussions
* Help to make a more resilient, connected community
* How does this fit - help vs. policing? Maybe an awkward fit, how do
we encourage people to ask us if we're seen as police?
We need to create a rubric of best practices for the AH team so that
current and future members can understand what we're trying to do, and
how to do it.
AH should pass on records to DAM and ask "what do you think?" rather
than saying "we recommend you take this particular action". It's much
easier to have a conversation with DAM early and refer matters to
them, rather than assuming there has to be a recommendation of action
to go with it.
Who should take responsibility over abusive comms (lists, blog, etc.)?
Any person can complain / give feedback, and AH will act as the
backstop: the people to talk to next.
Some people genuinely don't know what to do with CoC violations and
where to get help. We want to make it more explicit about how we
expect the CoC to work, so we're going to add some more guidance notes
at the bottom:
* It is the whole Debian community's responsibility to uphold this
code and make the community welcoming."
* If you feel that Debian or Debian events are not meeting this CoC,
please talk to ..."
AH should be the "People delegated to interpret the CoC".
"We feel that your communications are not consistent with the Debian
CoC; we ask you to please change your behaviour/wording/XXX" If there
is a disagreement with AH, where should people contact next?
Lismasters etc.? Appeal to the DPL? Go to a GR?
5.1 Events and AH
-----------------
Events support can be a lot more involved than other venues, and
details can fall through the cracks.
We don't want to just leave all of the responsibilities for this with
the local team, as it's a lot more effort and difficult to keep a
consistent stance and style. Also, we need to share knowledge and
experience from past incidents. Smaller events (miniconf, BSP, release
party) are more awkward due to scale and spread.
The AH team will try to write up an initial scope for project level
buy-in, prior to DC19. Then we can initially discuss at the DC BoF and
with a wider audience later.
How do we build trust in the AH team? It's very difficult by the very
nature of what we're doing. We don't have a public track record, by
design! Some people don't like that it's "those" people, not "people
like me" Can we "borrow" trust by inviting existing
well-trusted/well-connected people to join the team (ex-DPLs etc.)?
Discussions of awkward topics is hard. We're not wanting to ban ideas,
we're definitely *not* "thought police". Some topics just have no
bearing or relevance in Debian, so should not be cropping up in Debian
space. We ask for respect of other people, nothing more. Off-topic
discussions are off-topic and don't belong - that's an easier metric
to decide on, rather then evaluating based on other things.
So, what is the scope of the team? We want to be a resource for
mediating challenging communication and miscommunications. We will
pass reports to relevant teams if/when actions become necessary. We
will aid in the interpretion of the CoC. Fundamentally, we want to
help the Debian community become a more welcoming place for all.
6. AH is a bad name - ideas for something better?
=================================================
For quite a while we brainstormed a whole set of different names, some deliberately bad and a few that we thought might work.
We could easily identify a lot of bad names, including:
* AH :-)
* re-education team
* Debian police
* the CoC team
* the team we cant find a good name for team
* nice people
* welcome team (already taken)
* misbehaviour team
* frustrating team
* thought police
* the A team
* miscommunication(s) team
* mediation team
* the team that does more than you think
* the team formerly known as AH
* prince
* unity
We did find some better possibilities that describe what we're trying
to do (terms, not necessarily whole names):
* resolution
* cohesion
* respect
* community
* accord
* Communications and Resolution (CAR)
* Community and Respect (CAR)
* Community Cohesion (CC)
* Community Accord ()
* Community Rapport
In the end we came to an agreement on the new name we'd like to use:
"Community". It's a single word, with an obvious email address:
community@debian.org
7. Conflicts of interest
========================
Taking a personal interest in a case can/will cause problems later if
the (same) members of the team end up taking action. It will cause
people to lose trust in getting a fair hearing, so recusal is the
right answer here. It depends on having more people available, of
course.
There's a reasonable test to use: given previous discussion/actions,
would a "reasonable person" think that a team member is giving a fair
reception to discussion?
We expect that all team members of AH and DAM (and even DPL) will
mention conflicts of interest as they arrive, and offer to recuse
(take no part in the discussion). This *can* cause problems when we
only have small teams involved, of course. We need to recruit more AH
team members in particular to help here.
8. Salsa and suspended accounts
===============================
There's a worry that the current handling of suspended and emeritus
accounts on salsa is not good. A similar argument could be made for
mail forwarding and web password/sso. If somebody leaves Debian or has
their DD rights suspended, it becomes very difficult for them to
continue working on projects.
Sam plans to talk to salsa admins about salsa and suspended accounts.
9. Setting up better process for AH
===================================
Sledge will talk to DSA to sort out RT queues for AH and work out what
we need.
We could possibly share some things (conversation logs etc.) in an
IMAP folder etc. too - let's work out the best process as we go.
10. CoC - is it OK? Do we need to update it?
============================================
We agreed to change a couple of bits of context *around* the CoC:
* Assert it also clearly applies to Debian events
* Add the footer with contact info etc., as mentioned previously.
Sledge will prepare diffs and send round for review.
To actually modify the statements on the CoC pages, we probably would
need a GR, based on the original GR vote
(https://www.debian.org/vote/2014/vote_002). However, we can clarify
how we interpret it on the page and elsewhere. We assert that Debian
events are also places of communication - that should be obvious and
non-controversial.
How much leeway do we allow for "good faith" etc. in discussions? How
much is considered "thought policing"?
If we ever do update the CoC, we might think about adding something
about respecting boundaries.
11. Relationship between AH and DAM (and other teams)
=====================================================
How should we work with each other? We agreed that AH should get DAM
involved for advice and input much earlier - don't wait until things
have exploded. Also, we should be providing information to DAM, not
giving recommendations for action.
Once we have queues in place, let's use RT tickets as the central
location for information. Then we can mail things to RT as we find
them, share concerns, links etc. Then that's a good place to start the
conversation with all context in place.
DAM can step in at any point, but will ask AH before taking over a
case. Suggestions for when AH should involve DAM include (but are not
limited to):
* working with the people involved in a conflict does not seem to be
getting anywhere
* a recurring pattern of problematic behaviour - we can deal with it
again, but it's happening regularly and it should stop at some point
We *don't* have good points of contact for all of our various
teams. Should we make this more formal? Maybe have a confidential, not
publicly archived list of contacts for:
* listmasters
* dsa
* dam
* planet
* mentors
* various teams
* forums
* irc
* debconf
* community team
(and for each point, document what are the actual privacy issues, like if there are archives and who can read them)
Important teams / important services should be represented here, with
things like emergency contact details. This is separate from the
"house is on fire contact list" (with contacts, if applicable, for
different kinds of priority, like "house is not on fire, but I'd like
to let you know of something confidential". Ganneff agreed to start
organising an emergency contact list.
What should we do when things are "on fire"? It's possible to calm
lists by moderation/cross-assassin for a while. Difficult to do
similar for other fora. Suggestion to set up a "town hall" type
discussion for sensible moderated talk. Would that help?
12. Private discussions around current AH matters
=================================================
[ The meeting was a good opportunity for having face to face private
discussion about some of the current AH-related matters. ]
13. Distinguishing between tone policing and requiring constructive communication
=================================================================================
How should we document the line between tone policing/mindless
political correctness and requiring constructive communication
(https://lists.debian.org/debian-devel/2019/06/msg00227.html can be an
example explanation)?
Outbursts after lots of provocation are understandable, and we don't
want to punish people for individual incidents. However, some people
genuinely don't know how to react in "diversity" situations and are
worried about being punished for doing things wrong. We need to be
compassionate and understanding of all viewpoints, while also
encouraging people to be welcoming inside Debian.
14. How to encode/communicate "Everyone is responsible for Debian being a welcoming space"
==========================================================================================
People in the community need to be taken seriously even if they don't
wear a "hat"; we don't have to wait until officially-recognised team
members turn up to stop an abusive situation. We need to make this
clear. As already mentioned, we're going to update the footer on the
CoC to make this clearer. We're also planning to use templates and
links to helpful material on mails from the AH team. We need to prep
those!
15. Transparency guidelines
===========================
If needed, we have a DAM appeal procedure where things can be
disclosed *safely* without needing to make things totally public. That
can protect against incidents where people might use any public
information to help them abuse further.
17. What do we do if it all goes wrong and we have no further internal options?
===============================================================================
We're vulnerable to DoS, and there is not much we can do about
it. It's unlikely that we'll get too many people trying to damage the
project at once, we hope. But targeted, sustained trolling could
really hurt us. If it happens, we may need to spend more efforts on
technical solutions to trim discussions. We can look into further
options as needed
If we need to go further, we could maybe look into more professional
help, whether that takes us down the legal route or something more
like a social worker. It might be worth having somebody around to ask
for experienced support (e.g. cyber-bullying). It'sa lso probably
worth us looking for training for members of these teams. In future,
we might try and organise something for a day or two during DebCamp?
Quite a few things that could help:
* Conflict resolution (e.g. MVS, TotalSDI
https://totalsdi.com/assessments/the-power-of-the-sdi/)
* Incident response
* Team dynamics / interaction (e.g. Belbin roles
https://www.belbin.com/about/belbin-team-roles/)
* Facilitation / mediation could also be useful skills to import into
the project: the idea can be generalised
* Legal background?
We'll look into this. Can we look for trainer recommendations? Check
with company HR departments etc.?
18. How do we share experiences with other orgs?
================================================
Can we do this sensibly? We're not sure that our current privacy
policy lets us do this. Can/should we update it to allow this? There's
also a worry abour GDPR (etc.) claims - we may have to disclose some
data if it's requested. We should get clear guidelines on this, and
maybe warn people that some things cannot always be kept confidential.
We discussed some more about keeping / sharing contact lists with
other FLOSS/colunteer organisations. There clearly isn't a central
list here - could we work with others to make one for FLOSS orgs at
least? Should we add community@d.o as a generic contact address for
people to use? Probably not, due to workload. We should probably talk
to our derivatives and other projects, though.
19. Signing Diversity Statement or CoC together with other foundation documents during NM/new DM
================================================================================================
DAM has updated the nm.debian.org site to update the NM process. Along
with the DMUP etc., we will ask future NMs to signal agreement with
the CoC. Current DM/DDs will not be asked to re-sign any documents.
Steve, for the AH team
--
Steve McIntyre, Cambridge, UK. 93sam@debian.org
Debian Anti-Harassment Team
Attachment:
signature.asc
Description: PGP signature