Dear Debian: July was a huge month for Debian with the buster release [1] and DebConf 19[2]. I'm finally mostly recovered from the bugs I picked up on the plane trip back from DebConf. Being sick and the emotional intensity of July means this Bits from the DPL is a bit later than usual. I'd like to thank everyone involved both in the Buster release and in DebConf 19. We are doing great work. I had an exciting opportunity to sit down with Danny Haidar from the FreedomBox Foundation [3] at DebConf. For those who are not familiar, FreedomBox is a Debian Pure Blend [4] focused on providing a personal server in the home so we can take control of our data. Because it's a pure blend, all of the software on FreedomBox is in Debian; they have no custom patches to software they ship. FreedomBox has recently started focusing more on end users. They have started to sell prepackaged hardware, and have set up end-user facing websites and support channels. I was excited to learn that they are still committed to being a Debian Pure Blend. This will be an interesting challenge for us to work together and see whether the Pure Blends approach can work for an actual end user product. I think the closest thing we've tried so far is Debian Edu [5]. Unfortunately, things got off to a rocky start for FreedomBox with the Buster release. Many of their users ran into the Apt error that release information had changed [6]. The web GUI for configuring FreedomBox did not provide a way to approve the release info change. So, a bunch of users used to using a web interface for configuration needed to learn to ssh into their FreedomBox and fix the problem. I think this presents a great challenge to our community to figure out how we can bring Debian to an ever more diverse community of users. I also think it is an excellent reminder that the decisions we make in Debian have consequences for our downstreams. [1]: https://www.debian.org/News/2019/20190706 [2]: https://www.debian.org/News/2019/20190727 [3]: https://www.freedombox.org/ [4]: https://www.debian.org/blends/ [5]: https://wiki.debian.org/DebianEdu/ [6]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931566 Git and Packaging ================= At DebConf, we had a BOF [7] focused around collecting requirements about Git packaging and the use of Salsa for Debian packages. I'd like to thank Jonathan Carter and Ian Jackson for helping with that BOF. For me, the biggest news was there were no huge surprises. We didn't collect any particularly unexpected requirements. I think we are now at a point where we're ready to develop an informed consensus about our best practices. Thomas Goirand decided to explore short-circuiting that process and asked about proposing a general resolution [8] to set policy in this area. I do not think that a resolution is actually going to be proposed based on that discussion, although it is a bit unclear to me. If a resolution is proposed, I'll put my consensus work on hold until after that process resolves. I read the feedback in Thomas's discussion and will incorporate it into a discussion I plan to start on debian-devel. I plan to see if we can gain consensus around best practices for when to use Salsa, recommended maintainer branch formats, and a couple of other issues. Unlike the debhelper dh discussion, I do not anticipate us coming up with normative recommendations. Instead, I think we'll be able to come up with some best practices that we recommend to maintainers. Maintainers can choose to follow these practices when they are beneficial. Prior to DebConf, Ian Jackson and Sean Whitton held a dgit and Git Packaging sprint [9]. Several new features were added to dgit. The main result of the sprint was a tag2upload service[10]. The prototype allows users to explore what it would be like in an environment where they could perform uploads to the archive by pushing a git tag to Salsa. Ian produced a draft security architecture document [11] (or for an ephemeral link to the current version [12]). Ftpmaster members are concerned about the idea of source packages that cannot be verified back to a signature made by a developer. [7]: https://debconf19.debconf.org/talks/68-one-git-to-package-them-all-and-on-the-salsa-find-them/ [8]: https://lists.debian.org/msgid-search/d982c086-c05f-2df6-e5a7-492b504f954b@debian.org [9]: https://lists.debian.org/msgid-search/87bly2nwcf.fsf@iris.silentflame.com [10]: https://spwhitton.name/blog/entry/tag2upload/ [11]:https://lists.debian.org/msgid-search/23863.47814.346966.188900@chiark.greenend.org.uk [12]: https://salsa.debian.org/dgit-team/dgit/tree/wip.tag2upl-draft Community Team Status ===================== The Antiharassment Team is in the process of renaming itself to the community team. Steve McIntyre published the sprint report [13] from the AH/DAM/DPL sprint in Cambridge in June. One of the big changes from this report is that the team is renaming itself to the community team. I published the results of my survey of the Antiharassment/Community team [14]. I think we need to address two critical concerns that were highlighted in the survey and in earlier discussions on debian-private and debian-project. The first is working so that the team is more responsive; many of the issues brought to the Community Team cannot afford months for a response. The second concern is something that I called mediation in my message, but it's clear that's not a good name for it. We're definitely not talking about classical mediation either in terms of process or in terms of for example asking the Community Team to mediate technical disputes. But it does seem like we're talking about doing more on the de-escalation/helping people understand how to meet their needs within our standards front. I think there's more work to do to understand exactly what the project is looking for and what the team can deliver. [13]: https://lists.debian.org/msgid-search/20190719221744.GA30118@tack.einval.com [14]: https://lists.debian.org/msgid-search/tslwogr768h.fsf@suchdamage.org Community Team is Not Delegated =============================== I wanted to make some changes that I believe would help us get to a point where we're better able to address these concerns. We had a wide ranging discussion on debian-private about that. Some of the conclusions of that discussion need to be reported in a public forum. I had been assuming that we wanted to treat the Community Team approximately as if it were delegated: the DPL was relatively involved in thinking about the mission and staffing of the team. Based on feedback and talking to Steve, I decided to take a different approach. For now, we're deciding that Antiharassment is just a group of developers with no or more or less power than any group of developers who happen to self associate. You can go to them if you find their help valuable. You can come to me if you'd feel more comfortable with that. You can talk to others in the project if that works better for you. Some people have asked if this means you can ignore the Community Team if they come talk to you. You can treat the Community Team just as you would any (group of) developer who bring up a concern if they come talk to you. However, ignoring developers (regardless of whether they are the Community Team) who bring concerns to you is not generally appropriate. Sometimes we find that we don't work well with others in the project, and we need to find ways of responding to their issues while minimizing our interactions with them. That's fine, and feel free to reach out if you need help doing that. Ignoring members of our community who come to you is rarely the right answer. The Community Team is busy working to figure out what their proposal is for their scope as well as looking at recruiting new members. Long term, I think we'll want a delegation. It would be nice for the Community Team to be our recommended resource for conduct concerns rather than simply a resource people can go to. Long term, it would be valuable to have the Community Team interpret the Code of Conduct. I think that doing those things would require a delegation. Also, depending on what role the Community Team has in terms of helping coordinate incident response for Debian events, that might require a delegation. If the Community Team gets to a point where they want to explore delegation I will work with them. Nondelegated Entities in General ================================ So what does this mean in general? It's fairly common for teams to self organize and get busy doing their work. That's an important part of our success; we don't want to break it. Sometimes those teams accumulate documented or implied power. In general, that's fine too; we don't want to get in the way of people doing work. But as a team accumulates power, the project as a whole has an interest in considering whether that's where we want to place that power and what group of people should hold that responsibility. The DPL's delegation power is how we typically look at questions like that. So, if a DPL does have concerns about a non-delegated team, there are a couple of directions to take that are generally applicable. We can scale back the team until it is just a group of developers with no power. Alternatively, we can delegate the team and establish an agreed scope and agreed team membership. The preference of the team is an important factor to consider when making the decision of which direction to go. Absent a clear direction from the team, those involved in the debian-private discussion preferred that we have a presumption to prefer keeping the team non-delegated. In this instance this factor ended up being the deciding factor and so the Community Team is a non-delegated team with no power beyond what a group of developers have. I think this was a really helpful discussion and clarification about how we generally approach our teams. It tends to avoid situations where the DPL is thinking about directly adding or removing people from a team. Instead, in the cases where the DPL is looking at who does a job, they are very often thinking about a specific delegation. So, rather than arguing about whether adding or removing a particular name from a team is best, we can discuss whether a new set of names (presented as a slate) is a reasonable choice for handling some function in the project. It is a lot easier to explain why a particular set of people are good at a job than explaining why someone should be removed from a list or why one person was added and another was not. Delegation Advisory Group ========================= In dealing with people issues I value being very public about praise and quiet about concerns. When I make a delegation, I'm happy to share what I am looking for in delegating that team. For example I'll be happy to talk about the skills I think are important and the factors I'm considering when evaluating options. I'm happy to talk about why I think the option I pick is a good option for the project. I'm not going to talk about the options I didn't pick, generally not even on debian-private. Lists like debian-private are not good forums for discussing these decisions. Consensus is not a good decision making strategy for choosing who should do a job. Sharing a lot of information about choices not taken is unprofessional, can harm those who were being considered, can undermine the team that was chosen, and can undermine other teams in the project. So, how do we have accountability for delegation decisions? I liked one of the ideas that was tossed around and will be implementing it. I'm forming a Delegation Advisory Group. These will be people who I work with as I'm looking at delegations. I will share the information I'm using to make decisions, including confidential information and my own analysis. I'll ask them whether they think the delegation I'm making is reasonable. Ultimately, though, the delegation is still the DPL's decision. Clearly if the advisory group has remaining concerns at the time of delegation, these would need to be shared with at least debian-private. Expect mail to debian-project in the coming days with a proposed scope for this team. Treasurer and Finance ===================== A couple of issues regarding treasurer/finance will be prominent soon: * Earlier this year I suspended the automatic approval of reimbursement for attending a BSP. I want to have better documentation of that process, and I may want to explore the idea of running more of the BSP reimbursements through the BSP organizers. I want to get that process back online prior to anyone organizing a BSP that would be effected. As a reminder, the intent here is to improve our procedures, not to discourage people from having a BSP or using Debian money to help with that. * It looks like we'll be revisiting the treasurer team delegation at the request of some of the more active members of the team. We'd like to add new blood and thank those who are no longer active. Expect mail on debian-project at some point. Talks I gave ============ I gave a number of talks at DebConf besides helping with the Git BOF. I gave a keynote [15]. I think this talk is a good introduction to what I'm trying to accomplish as DPL and where I think we are. I also gave a talk about my experience writing command-line DJ software [16]. For me, this talk is much more about the power of free software to let us control our lives and the world than it is about any technical aspect of that project. Because of the commons we've created in Debian, I had the tools I needed to approach music in a way that can work for me. Free software let me feel unbelievably happy and empowered. I also want to thank all those who danced with me Tuesday and Thursday nights. The joy of those evenings will be with me always. Video is available for both talks now; I'll work to get slides available in the appropriate section of the DPL wiki soon. [15]: https://debconf19.debconf.org/talks/61-bits-from-the-dpl/ [16]: https://debconf19.debconf.org/talks/53-djcli-case-study-in-how-debian-opens-opportunities-for-those-with-different-needs/ In case you Missed it ===================== * The Technical Committee ran a BOF [17] in which they explored the question of how could the TC work better. If you've wanted to think about improvements to that process, they are soliciting your ideas. * Mini-DebConf Vaumarcus October 25-27[18] [17]: https://debconf19.debconf.org/talks/76-meet-the-technical-committee/ [18]: https://wiki.debian.org/DebianEvents/ch/2019/Vaumarcus Feedback ======== I got a lot of feedback in July. I am honored to work in such a wonderful community. I was impressed that we can be so successful at combining strong disagreement, being constructive, and caring for each other. Thanks to everyone who made that possible. As always, I am interested in more feedback both about Debian and about how I'm performing the DPL job. The leader@debian.org mailbox is open. --Sam
Attachment:
signature.asc
Description: PGP signature