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