Hi all!
The DPL, Debian Account Managers (DAM) and Community Team participated
in a sprint on 12th-15th January 2022. We had initially hoped this
could be an in-person event, but in the end that proved impossible and
we chose to hold the event entirely online. All team members were
invited, but time zones and other commitments meant not everybody
could attend all the sessions. The following people were present for
at least some of the sessions:
* Jonathan Carter - JC (DPL)
* Enrico Zini - EZ (DAM)
* Joerg Jaspert - JJ (DAM)
* Sam Hartman - SH (DAM)
* Jonathan Wiltshire - JW (DAM)
* Nicolas Dandrimont - ND (DAM)
* Steve McIntyre - SM (CT)
* Andy Cater - AC (CT)
* Jean-Philippe Mengual - JPM (CT)
* Molly de Blanc - MdB (CT)
## Summary
Sorry, this is a long document. We covered a lot of ground in four
days! Here's a quick TL;DR.
* We had a wide-ranging discussion about the roles and
responsibilities of our teams within Debian, and we have ideas on
how to improve the setup.
* We know that our processes and workflows are not as good as they
should be, we're going to work on that. We're managing OK on most
issues, but we don't always pick up on everything we should.
* Recruitment and retention of team members is an ongoing issue,
and we had a long conversation about what we might do here.
* Is our CoC fit for purpose?
## (Wed)
## Status updates
Each team presented a summary of current and recent issues. As the
vast majority of the cases include personal data, for the sake of
privacy this report will not give details about them.
## Lessons learned
On a more general note, we also discussed what lessons we have learned
in the teams from the issues we've worked on. These apply in a few
areas.
### Data handling
Processing and keeping track of data about people is difficult, but
sometimes necessary. When keeping records, we should be careful about
what we keep and how.
In cases of abusive behaviour, it helps to construct a timeline of
what's happened - this may be very important later. Therefore, logging
timestamps is useful. Similarly, we should keep a list of people
affected.
### Working effectively in our teams
Importantly (for team members and others!): don't be on your own,
don't feel like nobody's supporting you, ask for help (even multiple
times/regularly, if needed).
Spending project money on the skills of professionals is perfectly
reasonable, and we have money to pay for it. (This was discussed more
in-depth later. Raphaël et al are working on a survey about how people
in the community feel about spending money, which would help direct
these efforts.) Debian has contracted with lawyers to provide legal
advice in certain situations, and also has a contract with a
PR/anti-harassment organisation. It's fair to make use of people like
this when necessary.
It can be hard work to deal with issues. Time management and **input**
management can be critical so as not to be swamped. Being interrupted
at random times by bad stuff is very draining, and this can be hard to
manage. Some folks have individual tools to help here (e.g. to
temporarily pause email access), and we're going to look into sharing
the ideas we have. Tip: give something a priority and a separate
urgency so something can be **vital** but not **urgent**. Goal: Find
ways to re-distribute or transfer responsibility of handling emergency
situations.
### Working more generally
Generally we do have the support of the project when we do stuff, and
this is important to recognise. We'll often get complaints, but that's
likely to happen in any large group. It helps if we can share obvious
context/reasons for decisions, and not "just" a pattern of
micro-aggressions.
Reaching out to people **early** and asking "are things OK?" can very
often defuse things. It's good to stop small problems growing into big
ones. Equally, calling out apparently bad behaviour early can help. It
doesn't hurt to ask people to explain what they **really** mean if
they're being vague
## Burnout
Wider discussion. Burnout is a perennial problem everywhere in
Debian. Could we find people with experience here to reach out and
help others? The Ubuntu CoC includes "Step down considerately". People
are volunteers, but once you've volunteered it's not cool to just drop
things. We should all encourage people to take breaks. Consider
people's well-being: simple questions like "how are you doing?" cost
little, but can really help. Lots of people end up identifying with
the technical things they do, and that's a hard thing to
change/fix. It can be very difficult to step back and take "me" time,
allowing others to pick things up.
## (Thu)
## Team responsibilities
What do DAM and CT do? We had a discussion about what the teams do,
how they interact and what we might like to change. Obviously, we also
needed to understand the responsibilities and powers of the teams
first before going too deep into the membership question (below).
### DAM
DAM started as a check for new members, approving new accounts, and
closing down MIA / bad actors. It's evolved into a catch-all, and that
doesn't scale. There's way too much responsibility for a small number
of people holding just about all the power here. That manifests in a
few ways. People need better/earlier **feedback** rather than just
enforcement "you'll get kicked out if you misbehave". However, the
team can't be everywhere and intervene on everything, and community
management does not belong in the team's job description. Pervasive
micro-aggressions are difficult to deal with this way. Safety of a
community should be the responsibility of everyone in the community:
how do we encourage and empower Debian members to take on that
responsibility?
There's too much of a feeling that DAM is the "big stick" - any action
will be seen as "too much", yet inaction is also complained about. We
need to spread the load more, and get more community help to deal with
issues at the right level. Community involvement can involve general
community members sending messages in response to inappropriate
behaviour, making reports to CT, etc.
How do we encourage more people to speak up and say "that's wrong,
please be better" on IRC, mailing lists, etc.? There are examples of
this approach working. Take the debian-user list: - AC and others have
been encouraging users to speak up and help improve things. It's early
days, but it's improving.
We have quite a few people who are happy to ignore feedback from other
community members, only changing behaviour when approached by somebody
with "power". We feel that people should understand and engage with
feedback from others, not just when enforcement is
feared. Could/should we find expert help with best practices here?
DAM warnings are a heavy hammer, but we do need them as a high-value /
final warning level. We want more of the community to help, but they
need to stay as a sanction. Is there a problem that most of the
positive things that DAM might do have been delegated / out-sourced
elsewhere now?
### Community Team
CT has been delegated with little power to **enforce** anything
directly [1]. That's been basically working OK. CT doesn't have teeth
directly, but that's a feature. People come to the team for advice,
and that's what we want. Other teams can delegate power as needed, and
that's working. DAM have been hoping for more input from CT in bad
cases, but that's not been showing up yet in all cases.
If we did want to change things and add powers, what would/could be
needed? We had a few ideas:
* The ability to say "this discussion is dead, please stop here" ?
How would that work?
* Temporary list/BTS bans?
* Other ideas that could be done - limit to one mail/person/day
etc.
* Close some of the dead lists?
[1] https://lists.debian.org/debian-devel-announce/2020/08/msg00000.html
The CT is working on a document exploring / explaining the CoC, due
for publication soon. They've tried to expand on the existing doc and
make it clearer how they interpret things. They're not trying to
**change** the CoC, so much as give guidance on how they'd like it to
be understood.
### Authority / responsibility
There are some edge cases here that are problematic.
Debian is a private organisation and we have the right to choose not
to interact with people (e.g. fascists). Some have even complained
when we said that, which is disappointing. Should we update the CoC to
be clearer here?
If a (non-DD) member of the community does not follow our rules, who
can say they're not allowed? If they're not an official member of the
Debian Project, DAM technically does not have jurisdiction. The DPL
can claim power, but it's not 100% clear. IRC ops / listmasters / bugs
owner can block people in their areas. There's the possibility that an
individual team may object or refuse to ban - how would that play out?
What happens if teams disagree? For example: it may happen that the
DebConf local team or the wider DC orga team may want to ban someone
from attending a DebConf. What happens if these two teams disagree? Do
we override them? Should we do something about the lack of policy
here? Is it a problem we should try to solve?
Generally, we agreed that we need to keep records for future
discussions. We should make it clearer that Debian events must accept
the Debian CoC, and that may include not allowing entry to people who
have been barred from Debian. We don't have a clear list of such
people, and if we did sharing it could be awkward. Other organisations
manage this kind of thing (e.g. the National Pub Watch in the UK),
worth looking into options?
Finally: do we want to tweak the setup of DAM/CT here? We were not
sure we had enough to go on yet. It's an ongoing topic for further
discussion.
## DAM and CT membership
We've had it suggested that maybe we should vote for membership in
DAM/CT. We had a long discussion about possibilities here.
What problem(s) are we trying to solve here? Do we have a problem with
not enough people, and the same people doing all the jobs? Will we get
enough people wanting to help? If we're struggling to find enough
volunteers for tasks already, will voting magically help us find more
people? We know we have a problem with people burning out, and there's
always 1 worry about the teams becoming an "echo chamber". Would
voting help with people being too busy, or ineffective team
composition? We're not sure.
It's often seen as desirable to have people around with experience who
can help; however, should we plan/drive around having turnover
instead? Do we need a cultural shift to make this work?
Multiple mechanics questions... How would things work? Would we vote
for part of the team and leave some places open for appointment? Or
would we vote for new people and cycle new members in that way? There
are also maybe some worries about the effects of voting. There are
plenty of examples of other teams and groups we could look at. Some
organisations have a maximum term for team or board members, then a
required break before standing for re-election. Finally: **who** would
be allowed to vote here? It's easy to say "just DDs", but would that
be a reasonable thing for the CT?
If we filled positions just by voting, there's a worry that we might
end up with a group that's too limited in terms of diversity.
Diversity here would of course improve if we improve Debian as a whole
("the big end of the funnel"), but that's a bigger topic than we want
to deal with here. There are lots of ideas that people are already
working on.
The Community Team has some existing requirements. We like to see some
background of "soft" experience/training for members. Would we add
that as a requirement? Other teams often have setups for training and
knowledge requirements too, this is no different. We also demand that
members have to be DDs already, to help with accountability of
protecting things like personal data. Is this too much of a hindrance?
If we removed it, it **might** open up a larger pool of potential
members but with the potential risk of exposing issues that we would
want to keep strictly within the project's membership.
## Concerns and interactions with the project (and externally)
How do we get on with the rest of the project? Are we broadly in tune
with project beliefs? We're always concerned that we might be not
accurately representing what the wider project wants, but we have
clear intentions: we want to improve things overall. This can lead to
tensions.
We have influence to be able to do things and make changes, and
convince people to help. We have to do this wisely. We don't want to
be a bubble. Each action we take **may** make the next one harder. Do
we have a limited number of "action points" that we can spend in a
given time period? We end up having to consider the cost of our
actions, and this leads to pragmatism - some things are **hard** /
maybe not worth it.
We try our best to be open about what we do, and provide updates on
our activities. We know this is important, but like most volunteers we
can struggle to keep this up. Time and energy are always limited, and
we often don't have enough of each to be able to respond to every
issue. It's also difficult to find time to work on things before they
become a problem. We need more people to help with what we do, and
that's always been the case.
How do we get to a different place? We continue to try to make
improvements: to the project, to the way we work together, to our own
processes. Maybe some bigger changes are needed in terms of how we
organise things.
## (Fri)
## Policy around removal of DD rights
What happens when a person loses DD rights? We've had discussions
around this point recently. We don't have a clear agreement over the
right way to do things. This was **not** a plan to second-guess
previous specific DAM decisions, but rather an open discussion over
what general policy should be.
If a DD is removed for bad behaviour, should we allow DM rights for
them? We've already made it clear that we value acceptable behaviour
more than technical contributions, even where we will miss those
contributions. If we declare that somebody is no longer welcome as a
DD, do we want to continue working with them at all? Not everybody
agrees on the right outcome here; what's the feeling of the rest of
the project?
As a counterpoint: people should already be told when they're behaving
badly, not just when it comes to DAM warnings and removal. If DAM do
have to step in, a documented history is very helpful - it makes it
easier to make decisions later.
## Working with people you don't like
This question has been raised before in a few previous
conversations. Do people know that they don't have to work with
someone they don't like? Do they really not have to?
There are two parts of this question:
* Firstly, how do teams collaborate when there are issues between
them?
* Secondly, how do we ensure work gets done if someone on a team is
toxic or otherwise difficult to work with and drives others away?
Cases differ, and there are various axes one can use to look at
things: privilege/oppression (are people being discriminated against
because they're different, or are people being discriminated against
because they can't treat people respectfully?), interest of the
project (should a core project have only one maintainer because nobody
can work with them?), groups one has to work with (it's heavy to
refuse to work with the Technical Committee and Security Team and DSA
/ DAM / DPL / Delegates in general). This becomes a problem when
either it's being used to cover bad behaviour or when work is not
getting done.
Solutions can include finding different ways to adjust the work,
adjusting the people involved, and taking conduct actions where
appropriate. A group of delegates has a hard time to reasonably refuse
to work with someone, because they took some responsibility for the
project. A single delegate can, and it's a problem if the whole group
can't. Possible solutions include changing a delegation, finding new
people to work on a package or project, etc.
Things are bad when work isn't getting done. We don't have a good
culture of reporting these kinds of issues (e.g. people refusing to
work together). We have poor records and data collection on these
issues as well. (No one wants to be a "snitch" though.) How do you
distribute power and responsibility? Can we scale the project by
distributing "reputation tracking" to individual teams? In Debian,
people only have to do what they want to do when they want to do
it. It creates interesting dynamics about getting things done. People
should take responsibility and commit to them, possibly including
trying to work with everyone.
## Who has the responsibility / power to say "this person is not involved in Debian at all" ?
It's not explicitly covered anywhere, so this responsibility currently
falls "up" to the DPL, who should be able to delegate it. Delegating
this responsibility should only be done with agreement if that
happens, not pushed onto a team. Should we introduce this
responsibility in our foundational documents, as a project decision?
Maybe there should be an group / committee in charge of this, which
includes people from various teams? We've had discussions with ad hoc
groups of people to make this kind of decision in the past. That's
worked, but not sure it's ideal. We may not need a formal process
right now, but it may become necessary in the future?
## Better organisation and support for Debian
There are two parts to this.
Debian is not a legally-recognised entity and this is making some
things harder for us. It's probably worth having a wider discussion
about maybe changing our setup.
Dealing with non-technical stuff with deadlines can be very
time-consuming and draining. We're lacking support to help cope with
those. We need somebody like a "project manager" to pick up on things
and make sure that they get done, not forgotten or dropped due to
volunteer time pressures. We think we're OK making decisions on what
should be done, but often less good about following through with the
necessary actions. Is it time to maybe look at hiring some operations
people for things like this? Again, wider discussion...
## Recruitment, turnover and group capacity
We have a common problem in Debian - lots of teams are
over-worked/under-resourced. We're not trying to solve the general
case here, just DAM/CT for now!
In our specific cases, our teams and team members are often
overworked. Also: the work needed here is often very bursty and energy
draining, needed typically when people don't have the time
available. If we're having a hard time recruiting, is that because the
job is not reasonable? To do these jobs, members are expected to
understand technical stuff and also need to be able to deal with
complex social stuff too. There's typically no such thing as a
"correct" decision here. Timing is impossible to predict and plan
for. Work can be contentious - it may upset lots of people. Whenever
we do things, we end up bracing afterwards, waiting for fallout. That
needs improving: feedback is fine, but needs to be respectful.
This is a **very** different setup compared to corporate HR (for
example). People end up burning out due to a sense of obligation. :-(
So, there are two things to think about here:
### Working better
We need to make it easier for our existing people to be effective. SM
has a proposed workflow (apparently very similar to that used by the
LTS team!) to try and make the CT work better. He'll try and write
that up properly to share with people.
### Recruitment
We need to work on recruiting more volunteers. How does this work with
the wider/earlier discussion about team composition / voting etc.? We
have a small pool of potential applicants. There are multiple
difference classes of contributors to Debian. Are we doing a good job
of getting new volunteers interested in helping?
Another question: if we got a lot of new volunteers immediately, what
would we do with them? We often suck at "onboarding" in Debian -
companies do it, we don't? We need to describe what new people need to
know: "Where do I find ... ?" etc.
Recruiting for positions of responsibility is especially hard: "Can I
trust somebody I don't know?" **But** we don't want to only recruit
from the people we already know, as that leads to bubbles and lack of
diversity.
Can we better describe the roles we have (e.g. an operations person)?
How do we spread them out more? We don't necessarily have all the
skills we need, so how do find the people with those skills?
A lot of people feel that Debian can be an escape from tedious day-job
stuff. Will we find volunteers for that type of work? Should we be
thinking about hiring people to help with some of this? Lots of FOSS
projects end up hiring operations people first/only (e.g
Python/Gnome). Could/should we spend money on this too? This is yet
another thing that needs wider discussion in the project, of
course. Lots of things to consider around this. The Raphaël / Freexian
survey may help us all see how people think about this idea.
It's sometimes awkward to ask people to help on our teams
(e.g. they're already taking flak and adding them to the team would
make it worse). Unfortunately, harassment against folks from
marginalised communities can be an effective way to stop them helping
and gaining "power". It's a common problem that people with strong
opinions end up dominating organisations due to being most ready to
work on things. Are we filtering some people out from consideration
for roles before we ask them? Should we let them make their own
decisions?
Compared to a more corporate setup, there are three things we don't have:
* A conflict of interest policy (we've never needed one)
* A skills audit to find out where we are lacking
* A risk register / assessment of project wide risks.
Are these too much bureaucracy that we don't want to do as volunteers?
## (Sat)
## Support groups
This has been suggested as an idea, but but we've not really done much
with it yet. Effort should be spent to support people who are
abused/harassed etc., not just dealing with the abusers. The priority
so far has been to deal with stopping abuse. It would be good to work
on this and have the skill set in the project. Can we make a safe
space for people to talk about issues and provide support? Where
appropriate, as part of first response to people, we should also make
sure to ask how the complainant is doing. We should ask what we can do
to help people when they talk to us. These were suggested in the
incident response training that CT folks had a while back. We'll look
to update CT templates and checklists.
There's plenty of wider scope in terms of supporting each other (see
responses to mails about human loss, illness, etc.). The flip side is
a risk that it leads to bearing lots of psychological burden and to
burn-out if one gets too involved. We should consider the effects on
complainants / people affected when we do stuff. Get their input, and
tailor actions based on how it will affect them.
Can we get expert help here too? Companies might call in a grief
counsellor, for example. Other orgs (e.g. Wikimedia France) have
retained professionals like psychologists to help people if needed. We
could do similar, DPL likes the idea. We're OK at doing sociable chat
with people, but we're not in the right position to be able to offer
trained/professional help ourselves. There are multiple different
skill-sets here.
Let's not volunteer people to do things here where they don't have the
skills. We're going to look for possible solutions and/or providers in
this space. We already have a few suggestions of organisations who may
be able to help. To clarify: we know we have people already who can
provide Debian-specific advice, but not so much people with the skills
to help on other fronts.
## Code of Conduct
Some people say it doesn't actually help them very much in their work
here: they don't use it to guide actions/responses. There are no
mentions of privilege / oppression, which makes it difficult to use in
cases where that's an issue. Cases where people are "pushing buttons"
are particularly difficult to reconcile.
It can't be comprehensive, so there's always going to be lots of space
for interpretation. It's difficult to encode things in a reliable way
where figure skaters / rules lawyers won't try to abuse things. We're
not looking for a complete set of watertight rules, that would be
fruitless. Instead, like in several of our other important documents
this is a set of **guidelines**. We feel that the current CoC does not
follow current best practices in a few ways, but we also know that it
would be hard to change the wording. Instead, we plan to publish an
accompanying "this is how we interpret things" piece (as mentioned
above). We're not looking to **change** meanings of things, but to
make it clearer for everybody.
Side issue: We have lots of documents, scattered around - let's make
it easier to find things / merge some? It would be good to have a
single page linking to all of them, to make them easier to find for
new people. Also: are we missing a "netiquette" guide?
We should **not** be using the CoC as a hammer, a tool to punish
people. It's a set of guidelines, setting basic expectations about
interactions one is going to have with people in Debian. People make
mistakes - we're only human. Occasional problems will lead to
feedback/warnings. It's only if people get too many warnings that we
may have to do anything. Consistently/persistently being an asshole
**can** become a reason for removal, but obviously we never want it to
get that far.
There are some easy (and hard!) points to make here.
* Using privilege to attack someone is not allowed; opinions are no
less valid due to people being part of a marginalised
group. BUT... there is also a point where people in that group
can go too far in responses (e.g. the "f**k you") Where's the
line? It's very hard to say. It should be "common sense", but how
do we describe that? Should we warn all sides in a argument
regardless?
* It can be difficult to respond to people who want to troll about
"Freedom of Speech", classifying that as the most important
"right".
* Some trolls end up picking up and abusing the terms of the
marginalised, which is frustrating.
* How do we stop micro-aggressions that cause pain before they go
too far? Firstly, we need people to report them. We can make
warnings with clear links to educational resources (etc.). We do
track issues that are raised, so we can spot patterns over
time. We can't make everybody do training, but if we don't even
link to things then we're going to struggle.
* One message we want to make clear: we DO expect people to take
feedback on board. If you're told that your language or behaviour
is hurtful and people have **reasonable** suggestions for
improvement, we expect to see changes. Again, we don't want
people to see this as punishment. We hope to see genuine attempts
to improve, making the project a better place for all.
We looked at how other projects do things. A good example we found is
Wikimedia. They are currently reforming their community guidelines to
set a universal code of conduct baseline, as well as enforcement
rules, for all of the global Wikimedia projects [2]. A CoC is an
important document for many communities. How do they encode their own
rules and ideas? There's a **lot** of variation here!
[2] https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct/Project
## DAM working with other groups
How much can DAM lean on other groups to do things? This can become a
problem - "if nobody else can/will do it, DAM may have to". If it's
not clear, it can be more effort to find out / think about this than
just doing the task. Workflows differ between teams, and it's often
not clear if other teams are looking into issues and might be able to
help.
We need clear understandings of what each team can expect from the
others (a "wish-list of expectations"), and we need to communicate
more. We started on a discussion on how to do that. We agreed to
organise more regular sync-ups between various teams to help with
trust and responsibility.
## Finally - self analysis
We finished off by looking at how we'd deal with some hypothetical
situations that might happen to the project. "What would we do if...?"
Some cases are easy to deal with. Some are really hard. It can be too
easy to fall into a trap of "this is too hard, let's ignore it" which
essentially becomes a denial by lack of response. We need to be honest
about what we can and can't do. We won't be able to solve every case
raised with us, so it's only fair to tell people that.
--
Steve McIntyre 93sam@debian.org
Debian Community Team community@debian.org
Attachment:
signature.asc
Description: PGP signature