TL;DR: When I ran, I ran on a platform of working to gain the tools to heal from conflict in Debian. So far, I've focused on tools for making decisions. But for the rest of my current term as DPL, it is time to come back to that core focus and see what we can do to gain the facilities we need to listen without escalation and to heal from conflict. In this message, I outline some of the conflicts we've faced and talk about ways we might go forward. WE NEED YOUR HELP! If you would be willing to work to find ways to deescalate conflict in Debian, I'd like to hear from you. I like to start out by reflecting on some of the great aspects of Debian. There are two that were important in December. The first is all the great people who reach out when they notice things are rough and offer help and support. A number of people reached out to me to offer thanks for the work I was doing. That really meant a lot. I saw that was happening for other people. I wasn't the only one receiving gentle reminders that I was part of a community. Other people got that too from the people who could deliver that message to them. We are a community. Building a great free software operating system brings us together. But we care about each other, and we like to learn and work together. Whenever we manage to show that, we are stronger. Secondly, I'd like to call everyone's attention to the great work of the Project Secretary, Kurt Roeckx . The DPL and various delegates have ways in which they are charged to represent the interests of the project rather than their own personal goals. None more so than the Project Secretary. Ultimately, the fairness of the constitution and our general resolution process rests with the secretary. And we didn't make it easy this December. We found some ambiguities in how the constitution works. Kurt got stuck in the middle between a number of strong-willed participants (including myself). We were all arguing for what we thought was best for the project, but there was not always agreement in what that was. Kurt navigated that and delivered a quality resolution process. The secretary's job is not easy, but it is at the heart of our governance success. Thank you Kurt! In This Message: * Debian Does not Tolerate Intolerance * We had a General Resolution * Conduct and Community * Seeking Volunteers for Deescalation * See you at FOSDEM * In Case you Missed It Debian Does not Tolerate Intolerance ==================================== In December it became necessary for me to make a statement that using the pronouns people ask you to refer to them by is necessary for respectful communication in Debian [1]. If you will not do that, you are not welcome. I was not the only one saying similar things: members of the Community Team, listmaster, and several others spoke out. I want to expand on that statement and generalize it. This is a statement under Constitution section 5.1 (2). In some circumstances this statement may have power under 5.1 (4) and may serve as the basis for making decisions under 5.1 (3) when that is appropriate. In adopting the Code of Conduct [2] and Diversity Statement [3] Debian has committed to creating a welcoming community and to respect for the members of our community. This includes being welcoming to all peoples regardless of ability, age, country of origin, disability, gender, gender identity and expression, race, religion, and sexuality. Behavior that is inconsistent with creating this welcoming community will not be tolerated. We work with people to understand means and to help them meet the goals of our community, but those who cannot behave in a manner consistent with these standards will be asked to leave. [1]: https://lists.debian.org/msgid-search/tslk171vhxj.fsf@suchdamage.org [2]: https://www.debian.org/code_of_conduct [3]: https://www.debian.org/intro/diversity We Had a General Resolution =========================== Summary: Just before the new year, voting on the resolution on init systems and systemd concluded [4]. A new version of Policy was recently published reflecting the results of the GR [5]. I think we made great progress in figuring out how to make decisions when consensus is impossible. But the underlying conflict is still there: we need to heal from this conflict. Previously, the common wisdom was that options on the ballot should be written by a strong advocate. As I discussed in my last bits mail, I tried something different [6]. The winning option wasn't one that any of the major advocates on either side would have come up with. By trying to understand what people who were not heavily involved in the conflict thought, we came up with a new option. I think it is important that the entire community have a voice, and I am glad we found a way to do this. For me, this GR lends support that even when we cannot find consensus, facilitating discussion is valuable. Rafael Laboissière conducted a statistical analysis of the GR [7]. One of his conclusions is that the vote polarized the community. I came to the same conclusion using more crude methods. As a reminder, we define options ranked below further discussion as unacceptable, both in the constitution and ballot instructions. Of 425 voters, 112 found the winning option unacceptable. Of those, 38 would have preferred Proposal F, an even more systemd focused option to the winning option. Of the 112 voters who found the winning option unacceptable, 91 preferred an option that favored alternate init systems more. That is, over a quarter of the voters found the winning solution unacceptable. Just over 20% of the project found the winning option unacceptable and preferred that we focus more on alternate init systems. That's a lot of conflict; a lot of unhappy people. Some have suggested that what we need is more compromise, more middle ground. In the vote, we considered that. The authors and supporters of Proposal D and Proposal H worked towards that. They spent their effort and built the best common ground/compromise proposal they could. Even Proposal E acknowledged that some applications would be written exclusively for systemd and supported their inclusion in Debian. The project had an opportunity to consider compromise. The cost for that would be high too: 114/425 (just over a quarter) considered the best compromise position unacceptable. No matter what we did, we were in for a lot of disappointment. We're going to need to learn how to deal with this sort of conflict; learn how to heal from it, how to help each other out. In the DPL campaign period, we heard a bunch of people talking about the cost of not making decisions. We cannot simply ignore the conflicts and disagreements. Frustrations fester and we drive people away by being unable to decide. In this instance, people were hurt on both sides of the init system/systemd issue by how long we took to decide; I've talked about that in previous bits mails. I'm a huge fan of consensus building. But when over a quarter of your community considers the best compromise position unacceptable, consensus isn't going to help you much. Compromise isn't always the answer either. Sometimes we're just not going to agree. So then what do we do? Well, we make the decision. We've done that part. But now we need to try and find ways to deescalate tension while still respecting that decision. I don't entirely know what that looks like. I'm hoping we can figure it out together. If we're going to be a community that can move forward and face its disagreements, we will face this sort of conflict again. Let's figure out how to heal from it and be stronger. Some people will leave; some people will join. Let's find a way to honor that and grow from the experience. [4]: https://www.debian.org/vote/2019/vote_002 [5]: [🔎] 87eevtq5j7.fsf@iris.silentflame.com">https://lists.debian.org/msgid-search/[🔎] 87eevtq5j7.fsf@iris.silentflame.com [6]: https://lists.debian.org/msgid-search/tsl7e3ejgf4.fsf@suchdamage.org [7]: https://github.com/rlaboiss/debian-gr-systemd-2019 Conduct and Community ===================== Summary: The community team, account managers, listmasters and DPL are discussing how to improve communication in Debian. we're working toward a community team delegation and trying to understand how best to achieve the goal of creating a welcoming Debian. In more detail, there was some inappropriate conduct on debian-project and debian-vote. Good things about the situation: When someone popped up and proposed to do something that is not consistent with our standards, they heard on a number of fronts and in no uncertain terms that what they proposed to do was not consistent with our community. They left. While we are prepared to be welcoming to everyone, that's only true when people can interact constructively within our community, following our standards. When they cannot, it is good when they choose to leave. Unfortunately, the discussion escalated on a number of fronts. I don't know about the community team, listmaster and account managers, but I know I felt powerless to influence the situation. I felt that those charged by the project with maintaining our community didn't have enough confidence that we could support each other or that we agreed on how to respond. And so we were not able to respond as effectively as we would like. The discussion was needlessly painful and did not create a very welcoming environment. Regardless of our individual motivations, we found that we were all reaching out to each other, trying to figure out how to work more effectively in the future. 2019 was a year of tension around the Code of Conduct and creating a Welcoming Community. We need to find ways of deescalating and healing from this ongoing conflict. Foremost, we do need to make sure that Debian is welcoming, especially to marginalized members of the community. In 2019, we saw that the account managers and others were willing to take steps when our standards are not upheld. We do this because it empowers people. If people can trust that they have the support of the community when they are not respected, they can feel comfortable being here. Our community can grow. But naturally, this also frightens people. Change is frightening. Also, many of us have invested much of ourselves in the Debian community. We hope we will be treated fairly. Especially if we don't fully understand what is being required, we're going to have questions. Some are worried about whether Debian will continue to support their expression. We want to maintain a community that does support open debate of ideas. And sometimes there will be disagreements. There are members of our community who would like to see disputes around conduct handled in a legalistic manner similar to a court case. We don't have the resources for that, and there's overwhelming evidence that such systems protect harassers and do not create a safe space. Unfortunately, when all this fright, concern and disagreement gets mixed together into situations where people are actually hurt by how they are treated, it does not create a welcoming community. People believe that their requests to be treated with respect and requests for help will just turn into a flame war. Our focus becomes the meta-discussion rather than creating a welcoming community. We are so focused on how and whether to be welcoming that we deny any possibility of actually achieving that welcome. When people think of demanding respect, they are afraid, rather than confident. Yet we are a democratic community, and we are a community that works and grows together. We need to find ways for people to express their fears, to understand change, to argue for how things should be handled. Those arguments have produced positive artifacts: the account managers adopted an appeals process in response to feedback they received. This appeals process provides a better balance for our community than a more legalistic system. And even if some of the fears will turn out to be unjustified, we need to listen to them and give the members of our community space to process these changes. That needs to happen in a way that is respectful of everyone. Again, this is a source of conflict. We need healing. We need ways to make decisions about what our standards are. We need ways to listen to people's fears and input--whether you are marginalized, privileged, or it's so complicated no one can tell. But we need ways to separate that from responding to behavior that actually in unwelcoming or that otherwise does not meet our standards. Tensions are escalating (or at least escalated). we need to find ways to heal and deescalate that respect the people involved. Because of our governance, ultimately our policy will be set by the members. We've done much of that already by adopting the Code of Conduct and the Diversity Statement. Perhaps we need a bit more broad policy. If so, perhaps it does make sense to decide that as a project, either through consensus or GR. But project-level discussions have proven not to work as a forum for exploring the detailed standards of behavior for our community. It has turned into some fairly painful flame wars. It's not efficient. But also, it is an area where willingness to learn and to dedicate the time is important. Traditionally we've delegated such responsibilities. Just as we wouldn't expect the project as a whole to make release decisions, we (as a big community) need to be willing to let go somewhat and trust a smaller group to work on these problems. Yet again, that will bring forward fear and uncertainty. We will need to process, deescalate and heal from those reactions rather than allowing them to fester. Like responding to technical conflict, this is an area where I'm hoping we can work together and find the answers. Seeking Volunteers for Deescalation =================================== While discussing the role of the Community Team, I talked about my desire for the community team to help deescalate conflict. I used the dread m-word (mediation) and confused us all. Russ and others expressed doubt that this sort of deescalation was something we could accomplish. I think it is really important. We've demonstrated that we can make decisions; we can effect change. But for it to be healthy to do so, I think we need to deescalate and heal. The first question is whether we can find volunteers to work on that. I don't know whether it will fit into the Community Team: I think we need to see who volunteers, get input from the Community Team, and get input from the project. If you would be willing to help with deescalation, please reach out. Sorts of things this might include: * Working with people to make sure they are heard--whether it is a technical issue or a community issue. The point is not to judge or mediate, but to make sure that people and their opinions are not lost in the noise. And of course to raise the issue if they are getting lost. * work with people to split meta-issues away from discussions. So for example during the conduct discussions this December, provide reassurance that questions about our standards would eventually be heard, but help separate that from a discussion where we were trying to stand behind our transgender community. * work with people so they walk away from discussions feeling that they were considered. Try to figure out where frustration is festering and respond to that. * Provide reassurance. When we do need to take strong actions, help people understand how they can respond if they are nervous about whether they are meeting our standards. Help get them to a place where they have confidence that they could work constructively with the community if there were a concern. * Help people let go of past disagreements. I think this is an effort for which providing training would make a lot of sense. I'm also probably focusing on some things too much and doubtless excluding important things. The driving concern is to find a way of deescalating and healing. See you at FOSDEM 17= I'll be at FOSDEM and Copyleftconf. I am arriving Thursday before FOSDEM and will be at the mini Debian camp. I have obligations the second half of Friday. My greatest hope for this time is to find people interested in brainstorming and working on how to solve some of the issues I discuss in this bits mail. If you'd be interested in working with me and others in our community, please reach out. In Case You Missed It ===================== * There is a mini Debcamp prior to FOSDEM at the end of January [8] * There is a Ruby Sprint just after FOSDEM [9] * There is also an upcoming Treasurer sprint * The community team needs your help and seeks volunteers [10] [8]: https://wiki.debian.org/DebianEvents/be/2020/MiniDebCamp [9]: https://wiki.debian.org/Teams/Ruby/Meeting/Paris2020 [10]: [🔎] 20200110013144.GI6617@tack.einval.com">https://lists.debian.org/msgid-search/[🔎] 20200110013144.GI6617@tack.einval.com Feedback ======== As always, feedback is welcome, either in public or private.
Attachment:
signature.asc
Description: PGP signature