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

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE9Li3nMNy++OFgPTCQe7SUh/WssoFAl1SDvAACgkQQe7SUh/W ssr8GAf+Lixd3bCuq70xHIk9GOd3oKBDCJY5bnMKDksmPJLGrkRnBOHE7WAuvVGv CxBPXGy0s1REhku64j+eTX4dp2B+ZQ4dRCVA8FzKXGyYVCdFIUHPDDGn035bC2we u6RyKLFMUGTBvjx2dbI6LMXQxGqRThYeJK8roHb1jkEa+YR06ZPouAtaBocuQIl5 KYRljjyTmKp6yAh2ZImFUNEnVyvy1Kl4D/3JEYi+GNEJ7L1YNTe4h0q0m1WpxKAQ mDNtVrnn/QJtDfFvIlId88K5XecSn8jA5waOPkSyg1zdZOBaJB844p2tn5+rZ/b+ zGV1QIEYuDwsZRhHD/dxcRrstUZ5xg==AnTw
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)