It was a busy November in DPL land, but I'll get to that in a moment. I like to start out by focusing on some group in Debian. In October and November I had the opportunity to get to know the DebConf committee better. The DebConf committee is responsible for choosing the location of DebConf, for helping make sure that the broader DebConf team works smoothly, and for giving advice. Because of a number of resignations, I needed to focus on the DebConf committee to fill vacancies. It was a great process. The continuing members and I spoke about what qualifications we were looking for. We then talked about attributes we'd like to see in the committee. I raised an concern I had about the delegation (we decided to make no change). Then Daniel Lange made a call for nominations. We got both self nominations and nominations of others. I was nervous because back when I was on the Technical Committee, we always had trouble finding enough people who would answer our call for nominations. I guess DebConf is more fun than the TC:-) We got a large number of qualified candidates. Along the way, I felt like I got a better feel for the people involved, and some of the interesting challenges that DebConf faces. There's already been great discussion of how to balance the needs of local groups organizing DebConf against the larger community goals. Plus, work on Debconf 20 is starting to speed up. In this issue: To skim, find sections you care about and check the summary paragraph at the top to see if you want to read more. * Git Packaging * General Resolution on Init Systems * Being Excellent to Each Other * Upcoming DPL Travel * Treasurer Team Delegation Upcoming * In case You Missed It Git Packaging ============= We received enough comments and I believe we have a rough consensus supporting the discussion so far. [1] [2] [1]: https://lists.debian.org/msgid-search/tslv9t0uj2x.fsf@suchdamage.org [2]: https://lists.debian.org/msgid-search/tslsgmzdbgh.fsf@suchdamage.org I did not yet get a chance to write up the announcement of that discussion because I was very focused on init systems this month. In [2] I said that I wanted to move forward on a round 3 focusing on branch formats and similar. I'm holding off until after the holidays on that effort. I'm likely to try and hold the discussion for round 3 and fold the debian-devel-announce writeup of rounds 2 and 3 together. My rationale is that a couple of people commented that it would be better to have more clear recommendations on branch format, and if we can get that in round 3 of the discussion, we can fold that into something more useful for everyone. But right now, I don't think we're focused on Git packaging; at least I know that's not my current focus. [1]: https://lists.debian.org/msgid-search/tslv9t0uj2x.fsf@suchdamage.org [2]: https://lists.debian.org/msgid-search/tslsgmzdbgh.fsf@suchdamage.org Init Systems Resolution ======================= We're coming up on a vote about the role of init systems, how we use systemd facilities unrelated to starting daemons, and how we approach non-systemd init systems [3]. I think this is a important vote for the project and I encourage you to take the time to read about the proposals. Resources that might be helpful are at the end of this section. This vote is about more than just init systems. It's about the trade offs we make as a project. Generally we like to be able to encourage people in our community to work on whatever they like. But sometimes, to support that work, the rest of us need to help out: reviewing patches, commenting on proposals, integrating patches in related systems. One of our core principles is that we are not obligated to do work. But in order to get software into a release, we do have to do certain things. And when we look at staffing project-wide resources like the delegated teams, we work to make sure that we have the right people so that work gets done. This vote is about how we handle conflicts between a minority who would like to get something done in Debian and others who must look at that work as much as it is about init systems and systemd. I tried something new with this discussion. In the past only strong proponents of a particular option have proposed that option. Instead I tried to facilitate a GR process. I went out and talked to people on multiple sides of the issues. I did try to look for people who were willing to understand (if not agree with) other perspectives, and I tried to look for people who I could communicate with very effectively. My hope is that by coming to the community with some options, we could focus on refining options and seeing if their were viewpoints that were not represented. My hope was that we could skip the stage of arguing over what question we were trying to solve. We're not going to agree on what the question is: for some it is about init systems; for others it is about systemd facilities beyond init systems. For some it is about resolving specific issue, for others it is about what the project's general principles should be. For some it is about whether Debian continues to accept contributions of anyone willing to do the work, while others view it as a set of trade offs. We're not going to agree on what the key points are, but that's okay because we have a great voting system. Also, when one person presents an option, it's inherently somewhat confrontational. There's the question of whether we should be having a GR at all. There's one option, and we sometimes focus on arguing about that option. We argue and try to persuade rather than letting the vote make the decision. I hoped to side step that by quickly getting to a point where we were going to have a GR and where we had multiple options. I hoped that by doing that we could focus on refining and adding to those options and work together. I think it worked great. This discussion has been a lot of work from a lot of people. From my standpoint, with few exceptions, it's been a great discussion. It's been very productive. Most of the options received refinement. I think we have a very good ballot for the project. Perhaps it is just that time has passed since the last GR we had on this topic. But I believe it is more than that: I think that the facilitation work I did was also helpful, and hope that future DPLs will consider how they can work to help the project in time of GR. Very soon, we will reach the right time to make a call for votes. Based on feedback I received, I plan to extend the voting period an additional week because we're unsure how the holidays will effect things. Even though the discussion has been positive, this is hard. There is no answer where everyone's going to be happy. People may leave based on what we decide here. What I said about compassion last time around [4] will apply even more this time. Wow, I just re-read that message, and yes, I think that sort of care is something we need now, throughout the voting period, and after. We can help each other out even when we disagree. Let's try and be a community as this goes forward. We can reach out especially to people who hold different views. Let them know they are valued. Help them understand ways in which they can still contribute. If they decide Debian is no longer where they want to be, we can offer gratitude for their past work, compassion for now, and hopes for whatever future homes they find. If we can offer things that make it easier for members of our community to continue to feel welcome in Debian, I hope we do that. Unfortunately, we had such a great discussion that there was *a lot* of it. So, if you're looking for better understanding there's a lot of material you could read. At a minimum, there are the proposal texts at [3]. Beyond that minimum, I wrote a blog post that attempts to compare the options to help voters [5]. Ian Jackson wrote a similar blog post [6] a while earlier. There are a couple of options that got their own posts. I wrote [7] discussing Proposal B. Guillem Jover believes that we should be focusing on general principles rather than specific issues and wrote a post [8] explaining his Proposal G, which hopes to do that. If you get through those summaries, there are plenty of messages on debian-vote for you to sink your teeth into. [3]: https://www.debian.org/vote/2019/vote_002 [4]: https://lists.debian.org/debian-devel/2014/11/msg00133.html [5]: https://hartmans.livejournal.com/99642.html [6]: https://diziet.dreamwidth.org/3482.html [7]: https://hartmans.livejournal.com/99395.html [8]: https://lists.debian.org/msgid-search/20191202215533.GA257001@thunder.hadrons.org Being Excellent to Each Other ============================= TL;DR: Saying "I disagree, even I disagree and it would be really bad if Debian did x," is a *lot* easier to read than "you're wrong or that's stupid." How we express disagreement can be the difference from a fun and enjoyable Debian and a place that really sucks to be around. For the most part, being DPL has been a wonderful job. Even the recent discussions around init systems have been rewarding. They have been hard and intense, and they have taken up a lot of time. But that's the DPL job, and it can be very worthwhile. We disagree with each other often. Being disagreed with is also part of the DPL job. I've had people express really strong disagreement in ways that is relatively easy to hear. Yet there are a few messages (and sadly a few individuals who consistently) express disagreement in ways that make Debian kind of miserable to be part of. One fairly negative interaction in October had me at such an emotional low that I more or less ignored all but the most urgent tasks for about a week. Recently I was talking to a long-time contributor and said that I felt bullied. He had seen the interaction we were talking about and said that in the situation we were discussing he would feel bullied in my shoes. That was validating: it's nice to know it's not all in your head. But it also gave me pause. I don't want to promote a Debian where people push others around. The DPL job does involve disagreement. But neither I, nor any other DPL has signed up to be the project's punching bag. We aren't here for you to take out your strong emotions on. The DPL job is challenging enough without feeling dehumanized and disrespected. It's not just me. And fortunately today we've seen some great discussion of what it is about disagreement that makes it horrible to experience [9] [10]. Disagreement is easier to hear when there's room for the disagreement. When you state your disagreement as if there is room for the other side. As Russ says, "Stating these opinions as if they're uncontrovertible facts contributes to emotional burnout and makes Debian a less enjoyable project to interact with." I find that true of my experience in Debian. Even when 20 people pop up and say they disagree with me it can be OK. But when one or two people (especially if I respect their opinion) state their disagreement in such a way that they imply my opinion is beneath consideration, Debian is a hard place to be. Similarly, when they know there is disagreement and in response to that disagreement they state their position as a fact, completely ignoring the existence of other positions or of explanations of why they may be wrong, Debian is difficult. Please let us work on how we approach disagreement and work to make Debian a better place to be. One way we can work on this is to reach out (often in private) when we're hurt or when something comes across as problematic. I've done that a couple of times recently and gotten some very positive results. (If I've had such a conversation with you recently, thanks! Those conversations really do help.) Sometimes we'll learn that it is a language difference. Sometimes we'll better understand constraints that someone else is facing. Sometimes, as Russ did today, replying to the list is important. Knowing that we're not alone and that Debian does value creating a positive climate matters. [9]: https://lists.debian.org/msgid-search/87r21m7gg2.fsf@hope.eyrie.org [10]: https://lists.debian.org/msgid-search/871rtm6zre.fsf@hope.eyrie.org Upcoming DPL Travel =================== I will be attending the Thursday of the mini-debcamp prior to FOSDEM [11]. For the first time, I'm attending FOSDEM[12]. Then I hope to see some of you at Copyleftconf [13]. I'm very interested in meeting people and having any discussions that would advance Debian or cooperation with Debian at these events. [11]: https://wiki.debian.org/DebianEvents/be/2020/MiniDebCamp [12]: https://fosdem.org/2020/ [13]: https://2020.copyleftconf.org/ Treasurer Team Delegation ========================= Now that the DebConf Committee delegation is done, treasurer team is up next in the delegation queue. We've already received a number of volunteers back in July and August. We've done some of the preliminary work of discussing who is still active. I think there are a couple of questions where it would be valuable to get some feedback. Then we can confirm what tasks are most important to the project from a treasurer team and choose the right staff to get those tasks done. This process has been going slower than the treasurer team would like. I regret that, but delegations can be very important for all of us. In Case you Missed It ===================== When I said I was going to write a Bits from the DPL Mail, my wife asked if I was writing to tell Debian that going to the beach was a great solution to stress and making community better. I hadn't been planning on that. But in case you missed it, vacations in good locations with the right people are a wonderful way to make everything better. * There is an ongoing Debian Med bug squashing sprint in December [14] * Debian Janitor is a cool new project that tries to apply lintian-brush more automatically. This also isn't the kind of thing that normally goes here, but the project sounded so cool to me I was bouncing up and down so I decided to share. [15] * There is a mini Debcamp prior to FOSDEM at the end of January [11] [11]: https://wiki.debian.org/DebianEvents/be/2020/MiniDebCamp [14]: http://blog.alteholz.eu/2019/12/debian-med-bug-squashing-2/ [15]: https://www.jelmer.uk/debian-janitor.html
Attachment:
signature.asc
Description: PGP signature