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


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

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

iQEzBAEBCAAdFiEE9Li3nMNy++OFgPTCQe7SUh/WssoFAl3lxx8ACgkQQe7SUh/W ssqV9Af+LkA/l64nUx9k3qV154nccnEaff5OIlSZkkXky7XgBda87T5u/F3ACv38 RfJiS6UxB8s4dVlamyC1u1T7tG19xIkKvjItSyQDflXu3u4W6Bb2CHfVIhdSXTuS LKIWwCVg2tHOffGR0SGpiqYVV0XXMlXHskjWVyQQEqYqHByytIk1ib83Uda4ppx6 o6D7m4Lrle6t70Lkir4ebNPEl+J629sqzQkvJmTnlja4NFWpiDMekbRWN6c7FNmW mtXq4AZiE4LqD7e2dCeVlAVEiGyRnN6/+RwRze4CO5/TI4b2LmIEdoRiHq2WBqB1 jOFSqtZzQqgjsiJoM0PXoMQgyn0pvg==bY73
-----END PGP SIGNATURE-----

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