TL;DR: Overall, being DPL has been incredibly rewarding. I have enjoyed working with you all, and have enjoyed the opportunity to contribute to the Debian Project. I hope to be DPL again some year, but 2020 is the wrong year for me and for the project. So I will not nominate myself this year, but hope to do so some future year. I wanted to take some time to share my thoughts on my time as DPL, and some thoughts about the next year. Over the past year, we've done some great work. I'd like to start by acknowledging that and taking a moment to be proud of our accomplishments together. Consensus And Summaries: DH and Git =================================== In my platform I wrote: Debian is not fun when we face grueling, long, heated discussions. It is not fun when we are unable to move a project forward because we cannot figure out how to get our ideas considered or how to contribute effectively. Much of my focus at DPL was on a couple of experiments in decision making. Together I hoped we could show ourselves and the world that Debian can make decisions. I wanted to explore the DPL's role in accomplishing that. We succeeded. I facilitated a number of consensus-based discussions where we explored options and came to conclusions. In my mind the major elements of these were: * Starting with a statement of the problem area and a set of questions/observations about the current state of the discussion. * Giving people an opportunity to give input. * Indicating areas where we appeared to have an answer and areas where additional input was required; trying to cut off threads that were starting to repeat themselves. * Providing a summary so others could check that we got to the same place. * Feeding results of the discussion to the appropriate parts of the project. I think we succeeded at this work a number of times. From my standpoint, it was rewarding and energizing to see us actually make a decision and to get to a place where I thought we were not just repeating ourselves. For me and a number of other contributors I've talked to, discussions are less draining when we reach conclusions. I think I demonstrated that the DPL can be valuable in facilitating these discussions. I'm glad that I was able to explore more ways that the DPL could help the project. But what really made me happy is watching others copy this pattern. Yes, the DPL can facilitate, and for some project-level discussions that is the right answer. But anyone can implement the above steps. I saw a number of people do so. In particular, I think summaries at the end of discussions are incredibly important. It was great to see others doing that. It's great to see us learning together. This was an experiment. While I think we demonstrated that we can use this procedure to make decisions, we also brought forward a number of things to think about for the future. The biggest issue is that these discussions do take time and energy even when they eventually reach conclusions. I think we need to think carefully about when we need to make decisions as a project, or when other approaches are better. Also, one or two people can cause a consensus discussion to drag on much longer. As an example, it was obvious to me as a facilitator very early on in the Git Packaging discussion that we were not going to change our position on the use of Gitlab and other non-free services. Hundreds of messages were spent on a sub-thread that was never going to reach consensus. We need better tools for managing that use of our collective time while allowing each other to be heard. I think both of these are great areas to explore as we continue to improve Debian decision making. Facilitated GRs =============== In my platform I talked about how I thought the DPL's power to propose general resolutions could be used as a tool for facilitating discussion when consensus cannot work. We explored that together, and I think we did a great job of breaking a longstanding block in how we approach init systems. The traditional wisdom is that GRs should be proposed by a strong proponent of the option in question. I was dubious of this wisdom. It starts the process out on a confrontational note, rather than as a cooperative exploration of what the project wants. When consensus is impossible, there is inherent conflict. However, we can (and did) work together cooperatively to enumerate the options. I believe doing some ground work as a facilitator behind the scenes helped make that easier. There's another benefit though. By working to facilitate, I was able to hear options in the middle expressed by people who had opinions, but who were not involved enough to dedicate their time to go put that option forward. In this instance, that sort of compromise--collected from comments of bystanders rather than entrenched parties--won. Yes, there are dangers to compromise, but there are also dangers to only selecting from the positions on the edge as well. All in all, I'm very happy with the experiment of having a DPL more involved in facilitating a GR. We even demonstrated that multiple people who view things differently can get their options refined and supported on the ballot, so having someone facilitating added to rather than limited our ability to get options considered. During the process, we did discover a number of bugs in the voting system that really should be fixed before we have another controversial GR. Delegates and Project Needs =========================== One area where i was completely naive is in my understanding of how to manage delegations. I'm not talking about my interactions with the Community Team: yes I made some mistakes there, but I have every expectation that we'll have a Community Team delegation in place by the end of my term. I'm talking about the broader issues of how to see if delegates are doing what the project needs. On paper, the DPL has the power to adjust who is a delegate for a given position and to adjust what the task is. When people are stuck because of a disagreement with a delegate, because of inaction of a delegate, they often come to the DPL. I was hoping there would be some way to fairly explore ( in a small group or as a project) whether a particular delegation was meeting the current needs of the project. I did not find a way to succeed at that. The challenge is finding a way to evaluate whether a delegation is meeting our needs while respecting the time and effort that current delegates are bringing to the process. We need to find a way to ask ourselves whether delegations are meeting our needs without current delegates feeling defensive. When we need to make changes, it does not mean something negative about the current delegates. Often it means that the job we need done has changed or that there is value in looking at problems with new eyes. And yet, that's not how it comes across, either to the delegates or to the broader community. I also naively assumed that we could consider these changes as part of the normal part of doing delegation work. In practice, the DPL randomly gets notes from delegates, typically after the change has become de facto reality, asking for some change to be made in a delegation. These notes rarely have any discussion of the qualifications of people being added, the overall needs of the project in regard to the team's area of responsibility, or how the team believes their current staffing stacks up against these needs. I initially reacted fairly strongly to this, and got some really helpful advice showing me ways in which I was being naive. The kind of analysis of project needs that would be helpful is hard to come by. Often delegates are simply faced with a new person showing interest or an old person leaving. We don't want to turn away motivated new people waiting for detailed analysis of our needs. And yet, we've got to find some way to do better. We've got to find a way that we can adjust delegations as the needs of the project change without people taking it so personally. I have things I could learn about how to do that. but we as a community need to decide that we're actually going to be interested in exploring whether our delegations meet our current needs. I think we should encourage that exploration: * some of our teams are doing the best they can with some really hard constraints. We're frustrated because we want them to do things they don't have resources to do. And yet in some cases even if we explored trying to give them more resources we'd conclude we can't. So we could get to a position where we could say "Yeah, those folks are doing the best they can, and no we can't find a better way to do it." Coming to this realization would allow us to be more supportive of our teams rather than the current vague (or in some cases poignant) dissatisfaction. * Some of the time, people are doing the best they can with the resources they have. But sometimes we as a project might be happier if we got additional resources for the team, or changed the problem they are trying to solve. Today, we just let resentment build up: it's an us vs them mentality. * Some of our teams are low energy. Even if we had to reboot them, it might be better in the long run. * Rotation is is a huge win in the long run. Over time people can get set in how they think about problems and ideas. I've been an expert in a number of roles in my life. And every time I had to step aside, yes there were bumps. But within a year, someone had found some cool way to do things--something that I had not properly considered or even actively blocked. In most cases new people filled my shoes and we suddenly found ourselves with more people who understood the technology or who were experts. In some cases it turned out that the work was not valuable enough to the broader community to continue. But that's okay too. If I were running as DPL, figuring out how to do a better job of managing delegations, respecting both the current delegates and the needs of the project, would be my priority for the next year. I hope that the candidates who step forward take on this challenge. Technical Committee =================== Bluntly, the Technical Committee is an inadequate tool to deal with maintainers who are not cooperating with the larger community. The DPL gets a number of complaints where maintainers are blocking progress especially in areas where their packages overlap with others. Examples include people who interact negatively with the release process, or people who are so hard to deal with that they suck the joy out of Debian. Handling these cases with a public TC bug and a public vote is a dreadful process. Similarly, we run into problems when maintainers make decisions in their packages that affect a much broader community. Sometimes, maintainers do the work of driving the necessary discussions with that broader community. The discussion of changing default firewall rules for bullseye and of the impacts of persistant journal spring to mind as examples of handling this well. But when a maintainer doesn't have the necessary broader discussion, we have little recourse. The TC process is to heavy and too confrontational to be effective in these situations. In one case, I actually started talking to DAM about communication problems because that seemed like a more approachable and humane process than the TC. But in many cases DAM is way too big of a hammer (even if it's just going to be a warning issued initially). I'm not sure that the DPL is the right person to be looking at this sort of reform: the separation between the DPL and the TC is something that a DPL should be careful to consider. But this needs some attention in the upcoming time. Conflict Deescalation ===================== I've been talking about trying to find better ways to resolve conflicts in Debian since at least 2014. I continue to believe this issue is more pressing than ever. I've tried this from the side lines; I've tried this as a trainee in the Antiharassment team; I've tried this as a TC member; and I've tried this as the DPL. In my last bits from the DPL mail I've called for volunteers to try and help with this task. This joins calls and discussions I've made earlier. I have received no volunteers to help reduce conflict in Debian. The Community Team has made it clear that parts of this (if not all) are beyond their scope. The feedback I've generally gotten is that reducing the conflict in Debian is too hard. That we need to learn to crawl before we can walk, and that we are not ready to tackle this issue. We need to get an effective community team working, finish understanding what our Code of Conduct means in practice, and that sort of thing before we're ready to handle the sort of conflict deescalation I'm talking about. That may be true, but I also think the conflict is tearing us apart. Putting in the kind of energy and emotional commitment I've done over the last year is not something it would be safe for me or for the project without a better solution to conflict deescalation. The most positive message I've heard on this is that perhaps given some time it will all cool down and that if we are effective at actually making decisions, resentment and frustration will decrease without active help. That's probably partially true. But not true enough that I think it makes sense to have a high energy DPL without more people involved in deescalating from conflict. There are other positive things going on. A couple of the people joining the community team have relevant experience. I know of at least one talk being prepared for DebConf hoping to advance the discussion. Another member of the community indicated interest in working on mediation later in the year. so, I remain hopeful that we can make better progress on this in the future. Campaign of Harassment ====================== Throughout my entire term as DPL, Debian has been subjected to a campaign of harassment from a former project member. The primary thing I'm doing my last few months as DPL is dealing with lawyers. This is not a new thing: this issue persisted through much of my predecessor's term as well. I've always had respect for Chris, but seeing this now I stand in awe of anyone who could work as DPL under that kind of pressure. Whoever steps forward as DPL is going to need to spend some significant energy continuing to defend our community. You won't be alone. There are a number of people who are spending significant energy on this problem inside Debian and in the greater Free Software community. But I won't lie: it is a real emotional drag. Some people, hearing that this harassment is a factor in my decision not to run again, have said that they are worried we're letting "them" win. If I thought no one could step forward, I might agree. But there are people to step forward; there are people inside Debian and the broader Free Software community who do have energy. It's better for me to run my lap of the relay, heal and recover, and be ready to go again in the future. Besides, while this is a factor, it is not the primary factor. My overall reaction to this situation is disappointment and horror thinking about how much damage a single motivated person can do to a community. And yet, there are positive aspects to come out of this. We are facing this and growing as a community. Yes, there are still people who ask "why can't you just kill file this." But as a community, we've moved on from Usenet of the 1990's. The vast majority of people understand that in order to create a place where we want to work, we need to take care of each other. We all need to work on the effort of making our place desirable, rather than demanding that each of us spend that technical and emotional cost on their own. This situation is something that we can all understand. We can all empathize with the harm that members of our community are seeing. And we're starting to see results. People are working together, building emotional support mechanisms, building connections with professionals, and taking social and technical steps to defend our community. I regret the necessity. I regret that even on an issue like this, it sometimes seems like there is needless debate. But when I step past all that, I'm proud to be a member of a community that does care about its members, and that once the wheels start to turn will make changes to grow. Conclusions =========== For me the deciding factor was the lack of other interest from people interested in Conflict Deescalation. That was the most important thing I hoped to move forward during my term. I am very happy with my term overall, but I am disappointed that I didn't move this task forward. I've considered whether I should let this item go. But no, I still care about compassion, connection, and finding ways to approach conflict in Debian maintaining more of the above as much as I did in 2014. My heart wouldn't be in a second term right now without a plan to move this forward. It's time to let another person take a try. As I said above rotation is good: perhaps someone else will find a way to look at this and succeed where I haven't so far. Also, as I said above, there is motion on this front. I am available to help, especially on the issue of conflict deescalation and compassion. I hope to stay involved, and I hope to be back as DPL some day. Debian is one of my homes.
Description: PGP signature