TL;DR: When I ran, I ran on a platform of working to gain the tools to
heal from conflict in Debian. So far, I've focused on tools for making decisions. But for the rest of my current term as DPL, it is time to
come back to that core focus and see what we can do to gain the
facilities we need to listen without escalation and to heal from
conflict. In this message, I outline some of the conflicts we've faced
and talk about ways we might go forward. WE NEED YOUR HELP! If you
would be willing to work to find ways to deescalate conflict in Debian,
I'd like to hear from you.

I like to start out by reflecting on some of the great aspects of
Debian. There are two that were important in December.

The first is all the great people who reach out when they notice things
are rough and offer help and support. A number of people reached out to
me to offer thanks for the work I was doing. That really meant a lot.

I saw that was happening for other people. I wasn't the only one
receiving gentle reminders that I was part of a community. Other people
got that too from the people who could deliver that message to them.

We are a community. Building a great free software operating system
brings us together. But we care about each other, and we like to learn
and work together. Whenever we manage to show that, we are stronger.

Secondly, I'd like to call everyone's attention to the great work of the Project Secretary, Kurt Roeckx . The DPL and various delegates have
ways in which they are charged to represent the interests of the project
rather than their own personal goals. None more so than the Project
Secretary. Ultimately, the fairness of the constitution and our general resolution process rests with the secretary.
And we didn't make it easy this December.

We found some ambiguities in how the constitution works. Kurt got stuck
in the middle between a number of strong-willed participants (including myself). We were all arguing for what we thought was best for the
project, but there was not always agreement in what that was. Kurt
navigated that and delivered a quality resolution process.

The secretary's job is not easy, but it is at the heart of our
governance success. Thank you Kurt!

In This Message:

* Debian Does not Tolerate Intolerance
* We had a General Resolution
* Conduct and Community
* Seeking Volunteers for Deescalation
* See you at FOSDEM
* In Case you Missed It


Debian Does not Tolerate Intolerance
====================================

In December it became necessary for me to make a statement that using
the pronouns people ask you to refer to them by is necessary for
respectful communication in Debian [1]. If you will not do that, you
are not welcome. I was not the only one saying
similar things: members of the Community Team, listmaster, and several
others spoke out.

I want to expand on that statement and generalize it.
This is a statement under Constitution section 5.1 (2). In some
circumstances this statement may have power under 5.1 (4) and may serve
as the basis for making decisions under 5.1 (3) when that is
appropriate.

In adopting the Code of Conduct [2] and Diversity Statement [3] Debian
has committed to creating a welcoming community and to respect for the
members of our community. This includes being welcoming to all peoples regardless of ability, age, country of origin, disability, gender,
gender identity and expression, race, religion, and sexuality.

Behavior that is inconsistent with creating this welcoming community
will not be tolerated. We work with people to understand
means and to help them meet the goals of our community, but those who
cannot behave in a manner consistent with these standards will be asked
to leave.


[1]:
https://lists.debian.org/msgid-search/tslk171vhxj.fsf@suchdamage.org
[2]: https://www.debian.org/code_of_conduct
[3]: https://www.debian.org/intro/diversity

We Had a General Resolution
===========================

Summary:
Just before the new year, voting on the resolution on init systems and
systemd concluded [4]. A new version of Policy was recently published reflecting the results of the GR [5]. I think we made great progress in figuring out how to make decisions when consensus is impossible. But
the underlying conflict is still there: we need to heal from this
conflict.

Previously, the common wisdom was that options on the ballot should be
written by a strong advocate. As I discussed in my last bits mail, I
tried something different [6].


The winning option wasn't one that any of the major advocates on either
side would have come up with. By trying to understand what people who
were not heavily involved in the conflict thought, we came up with a new option. I think it is important that the entire community have a voice,
and I am glad we found a way to do this.
For me, this GR lends support that even when we cannot find consensus, facilitating discussion is valuable.

Rafael Laboissière conducted a statistical analysis of the GR [7]. One
of his conclusions is that the vote polarized the community. I came to
the same conclusion using more crude methods. As a reminder, we define
options ranked below further discussion as unacceptable, both in the constitution and ballot instructions. Of 425 voters, 112 found the
winning option unacceptable. Of those, 38 would have preferred Proposal
F, an even more systemd focused option to the winning option. Of the
112 voters who found the winning option unacceptable, 91 preferred an
option that favored alternate init systems more. That is, over a
quarter of the voters found the winning solution unacceptable. Just
over 20% of the project found the winning option unacceptable and
preferred that we focus more on alternate init systems.

That's a lot of conflict; a lot of unhappy people.

Some have suggested that what we need is more compromise, more middle
ground. In the vote, we considered that. The authors and supporters of Proposal D and Proposal H worked towards that. They spent their effort
and built the best common ground/compromise proposal they could. Even
Proposal E acknowledged that some applications would be written
exclusively for systemd and supported their inclusion in Debian.
The project had an opportunity to consider compromise. The cost for
that would be high too: 114/425 (just over a quarter) considered the
best compromise position unacceptable.
No matter what we did, we were in for a lot of disappointment.

We're going to need to learn how to deal with this sort of conflict;
learn how to heal from it, how to help each other out. In the DPL
campaign period, we heard a bunch of people talking about the cost of
not making decisions. We cannot simply ignore the conflicts and
disagreements. Frustrations fester and we drive people away by being
unable to decide. In this instance, people were hurt on both sides of
the init system/systemd issue by how long we took to decide; I've talked
about that in previous bits mails.

I'm a huge fan of consensus building. But when over a quarter of your community considers the best compromise position unacceptable, consensus
isn't going to help you much.
Compromise isn't always the answer either.
Sometimes we're just not going to agree.

So then what do we do?
Well, we make the decision. We've done that part.
But now we need to try and find ways to deescalate tension while still respecting that decision.

I don't entirely know what that looks like. I'm hoping we can figure it
out together. If we're going to be a community that can move forward
and face its disagreements, we will face this sort of conflict again.
Let's figure out how to heal from it and be stronger.
Some people will leave; some people will join.
Let's find a way to honor that and grow from the experience.

[4]: https://www.debian.org/vote/2019/vote_002
[5]:
https://lists.debian.org/msgid-search/87eevtq5j7.fsf@iris.silentflame.com
[6]:
https://lists.debian.org/msgid-search/tsl7e3ejgf4.fsf@suchdamage.org
[7]: https://github.com/rlaboiss/debian-gr-systemd-2019

Conduct and Community
=====================

Summary: The community team, account managers, listmasters and DPL are discussing how to improve communication in Debian. we're working toward
a community team delegation and trying to understand how best to achieve
the goal of creating a welcoming Debian.

In more detail, there was some inappropriate conduct on debian-project
and debian-vote. Good things about the situation: When someone popped
up and proposed to do something that is not consistent with our
standards, they heard on a number of fronts and in no uncertain terms
that what they proposed to do was not consistent with our community.
They left. While we are prepared to be welcoming to everyone, that's
only true when people can interact constructively within our community, following our standards. When they cannot, it is good when they choose
to leave.

Unfortunately, the discussion escalated on a number of fronts. I don't
know about the community team, listmaster and account managers, but I
know I felt powerless to influence the situation. I felt that those
charged by the project with maintaining our community didn't have enough confidence that we could support each other or that we agreed on how to respond. And so we were not able to respond as effectively as we would
like. The discussion was needlessly painful and did not create a
very welcoming environment.

Regardless of our individual motivations, we found that we were all
reaching out to each other, trying to figure out how to work more
effectively in the future.

2019 was a year of tension around the Code of Conduct and creating a
Welcoming Community.
We need to find ways of deescalating and healing from this ongoing
conflict.

Foremost, we do need to make sure that Debian is welcoming, especially
to marginalized members of the community.
In 2019, we saw that the account managers and others were willing to
take steps when our standards are not upheld.
We do this because it empowers people. If people can trust that
they have the support of the community when they are not respected, they
can feel comfortable being here. Our community can grow.

But naturally, this also frightens people. Change is frightening.
Also, many of us have invested much of ourselves in the Debian
community. We hope we will be treated fairly. Especially if we don't
fully understand what is being required, we're going to have questions.

Some are worried about whether Debian will continue to support their expression. We want to maintain a community that does support open
debate of ideas.


And sometimes there will be disagreements. There are members of our
community who would like to see disputes around conduct handled in a
legalistic manner similar to a court case. We don't have the resources
for that, and there's overwhelming evidence that such systems protect
harassers and do not create a safe space.

Unfortunately, when all this fright, concern and disagreement gets mixed together into situations where people are actually hurt by how they are treated, it does not create a welcoming community. People believe that
their requests to be treated with respect and requests for help will
just turn into a flame war.
Our focus becomes the meta-discussion rather than creating a welcoming community.
We are so focused on how and whether to be welcoming that we deny any possibility of actually achieving that welcome.
When people think of demanding respect, they are afraid, rather than
confident.

Yet we are a democratic community, and we are a community that works and
grows together. We need to find ways for people to express their fears,
to understand change, to argue for how things should be handled. Those arguments have produced positive artifacts: the account managers adopted
an appeals process in response to feedback they received. This appeals
process provides a better balance for our community than a more
legalistic system.

And even if some of the fears will turn out to be unjustified, we need
to listen to them and give the members of our community space to process
these changes. That needs to happen in a way that is respectful of everyone.

Again, this is a source of conflict. We need healing. We need ways to
make decisions about what our standards are. We need ways to listen to people's fears and input--whether you are marginalized, privileged, or
it's so complicated no one can tell.

But we need ways to separate that from responding to behavior that
actually in unwelcoming or that otherwise does not meet our standards.

Tensions are escalating (or at least escalated).
we need to find ways to heal and deescalate that respect the people
involved.

Because of our governance, ultimately our policy will be set by the
members. We've done much of that already by adopting the Code of
Conduct and the Diversity Statement.
Perhaps we need a bit more broad policy. If so, perhaps it does make
sense to decide that as a project, either through consensus or GR.

But project-level discussions have proven not to work as a forum for
exploring the detailed standards of behavior for our community. It has
turned into some fairly painful flame wars. It's not efficient. But
also, it is an area where willingness to learn and to dedicate the time
is important. Traditionally we've delegated such responsibilities.
Just as we wouldn't expect the project as a whole to make release
decisions, we (as a big community) need to be willing to let go somewhat
and trust a smaller group to work on these problems.

Yet again, that will bring forward fear and uncertainty. We will need
to process, deescalate and heal from those reactions rather than
allowing them to fester.

Like responding to technical conflict, this is an area where I'm hoping
we can work together and find the answers.

Seeking Volunteers for Deescalation
===================================

While discussing the role of the Community Team, I talked about my
desire for the community team to help deescalate conflict. I used the
dread m-word (mediation) and confused us all.
Russ and others expressed doubt that this sort of deescalation was
something we could accomplish.

I think it is really important. We've demonstrated that we can make
decisions; we can effect change. But for it to be healthy to do so, I
think we need to deescalate and heal.

The first question is whether we can find volunteers to work on that.
I don't know whether it will fit into the Community Team: I think we
need to see who volunteers, get input from the Community Team, and get
input from the project.


If you would be willing to help with deescalation, please reach out.

Sorts of things this might include:

* Working with people to make sure they are heard--whether it is a
technical issue or a community issue. The point is not to judge or
mediate, but to make sure that people and their opinions are not lost
in the noise. And of course to raise the issue if they are getting
lost.

* work with people to split meta-issues away from discussions. So for
example during the conduct discussions this December, provide
reassurance that questions about our standards would eventually be
heard, but help separate that from a discussion where we were trying
to stand behind our transgender community.

* work with people so they walk away from discussions feeling that they
were considered. Try to figure out where frustration is festering and
respond to that.

* Provide reassurance. When we do need to take strong actions, help
people understand how they can respond if they are nervous about
whether they are meeting our standards. Help get them to a place
where they have confidence that they could work constructively with
the community if there were a concern.

* Help people let go of past disagreements.

I think this is an effort for which providing training would make a lot
of sense.
I'm also probably focusing on some things too much and doubtless
excluding important things.

The driving concern is to find a way of deescalating and healing.

See you at FOSDEM
17=

I'll be at FOSDEM and Copyleftconf.
I am arriving Thursday before FOSDEM and will be at the mini Debian
camp.
I have obligations the second half of Friday.

My greatest hope for this time is to find people interested in
brainstorming and working on how to solve some of the issues I discuss
in this bits mail.
If you'd be interested in working with me and others in our community,
please reach out.

In Case You Missed It
=====================

* There is a mini Debcamp prior to FOSDEM at the end of January [8]

* There is a Ruby Sprint just after FOSDEM [9]

* There is also an upcoming Treasurer sprint

* The community team needs your help and seeks volunteers [10]

[8]: https://wiki.debian.org/DebianEvents/be/2020/MiniDebCamp
[9]: https://wiki.debian.org/Teams/Ruby/Meeting/Paris2020
[10]: https://lists.debian.org/msgid-search/20200110013144.GI6617@tack.einval.com

Feedback
========

As always, feedback is welcome, either in public or private.


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

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

iQEzBAEBCAAdFiEE9Li3nMNy++OFgPTCQe7SUh/WssoFAl4nURsACgkQQe7SUh/W ssodRQgAtWjUcsoRE1CiRSt0XluJ1O2NOmaD/7zInYZmRFKNR+j9DRhcz2+SVUQ2 HX2s0CPxYEfgnmIod857ubRllY5NtRBH/RMVG8DZOf88kqmsuDcYNfw6yM+ViTU3 uupbl4JXXLC8h1vWSjJiJxmvyUbPk25onqAviOfpcPgTkqOACoofR1OC9NhSipL3 IUzr7Pj/grETTJgi55oNKCOmMeHjT3FMxEjnkO97tphb/El4y8XZYi436i9fr1dZ nE/SD2jbu9DYQCcd04QVC5SRiD7I3ZMY95gG3wIsba8iiB6jzNMIqnoMrGBUpafX 4/ofzSo3bVvDAgRkmVF9dXf11WxjuQ=înr
-----END PGP SIGNATURE-----

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