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.
Sam,
Thank you for your work as DPL. I just want to add one thought about your takeaway that maybe the project isn't ready for a "high-energy DPL". I don't think we should discourage folks who have "high-energy" and free time to work on Debian (as DPL).
Everyone working on Debian just needs to always remember that there is common ground, and we need to work around the areas of conflict. In other words "pick your battles" (carefully), because we as the Debian family have some strong common bonds, and it's a shame to break or damage those bonds.
There is so much work that we could be doing that we don't have time for, that aren't "battles". For example, I don't know what happened to "Debian PPAs"? As I understood, there was a broad consensus that this would be a great thing, but no one had time to do the work. I'd love to see a motivated DPL, come in and "make it happen". (It doesn't need to be a DPL, but this is just one example.)
Cheers,
Brian