Re: Draft proposal for resolution process changes
Felix Lechner <felix.lechner@lease-up.com> writes:
> Thank you for your lengthy and thoughtful reply. Sorry if it seems
> like I hijacked your thread.
No, no, this is great. The whole point is to have an open discussion.
Thank you very much for your thoughtful message! I think you're raising
some very interesting issues that are worth discussing.
I'm about to write a lot about philosophy and my personal opinions, so I
do want to say up-front that I don't think anyone has to agree with my
opinions about this (or about anything else in Debian for that matter) to
support the change that I'm proposing. I've attempted to keep that
philosophy out of the proposal itself. My goal is a proposal that anyone
can support as long as they agree that:
* We currently need an explicit and clearly-specified decision-making
process for the Technical Committee and the Developers via General
Resolution.
* The current systems for both are confusing and somewhat unclear, and
have loopholes that have caused frustration and perceptions of
unfairness in the past.
* This proposal is an incremental improvement in clarity and fairness
without losing any valuable properties of the existing systems.
The one trade-off decision that I'm explicitly making is that, given the
past problems and complaints about issues with vote timing, I've made the
timing of votes less flexible in order to make them more predictable.
That being said, I'll now dive into my own personal philosophical
opinions.
> On Tue, Sep 28, 2021 at 1:04 PM Russ Allbery <rra@debian.org> wrote:
>> I'm reading this as another message of support for a tied vote in the
>> TC to result in an outcome of further discussion or to automatically
>> set off a GR. Let me know if I misunderstood.
> My point was broader. I envision nothing "automatic" but would leave it
> instead to the TC Chair, in a living process, to precipitate an outcome
> that survives public scrutiny and even outcry.
My counter-argument is that we have concrete past experience with this
approach and we didn't enjoy the experience. All sides felt like the
process led to procedural maneuvering and uncertainty that created a lot
of pain and hurt.
My goal for the TC section is to make explicit the rules around ballot
construction and how a proposal comes to a vote.
The process I'm proposing arguably favors the opposite side from my own in
the TC decision that primarily prompted this change and would have
prevented the process that indeed happened. By this, I don't mean to
imply that the decisions at the time were wrong given the situation and
what we knew at the time (I think the situation was complex and I don't
want to take a position on that at all). But with the benefit of a few
years of hindsight and watching subsequent GRs, I think a simpler process
with clearer rules and less flexibility would have had a better social
outcome for the project.
One of the significant problems at the time was that the constitution
specified almost nothing about how TC votes were started, and we were
unable to reach consensus on that in the middle of a contentious debate
because the procedural issues and the substantitive issues weren't
emotionally separable (at least for me, and I think I'm not alone). This
is the whole point of having a process written down in advance, and in the
absence of any specific issue in mind: it lets us establish agreement on
the process without being in the heat of a specific disagreement, and then
fall back on that process agreement when trying to navigate a tricky
decision.
I find having an explicit process to use as a structure for navigating a
disagreement to be calming and supportive. It makes me feel like I have
firm ground under my feet and space to think when I know procedurally what
I can and can't do in order to argue my perspective.
> Your concerns about tactical voting may be better handled by
> observers—such as the press, or fearless advocates of transparency like
> Adrian—while the process unfolds.
Addressing tactical voting via transparency only works if the people who
are voting tactically are likely to change their behavior because of that
transparency. I do not believe this is true. In a system that creates
incentives for tactical voting, I don't believe people who then vote
tactically are doing anything wrong, and therefore they have no reason to
fear transparency and have no reason to change their behavior regardless
of the opinions of observers.
The problem with tactical voting is technical: it makes your voting system
less likely to produce a fair outcome, where fair has a specific technical
definition based on the mapping of preferencs of voters to outcomes. My
goal in avoiding tactical voting is not that I think tactical voting is
somehow unethical (I don't believe it is), but that it represents a lost
opportunity for a better system (at least up to the limits of Arrow's
theorem).
> For the writer of a constitution, fear weakens the document's intuitive
> appeal, however imprecise the wording may seem.
For whatever it's worth, I didn't feel the emotion of fear when I was
writing my proposal and don't feel any fear now, and I don't believe that
I'm expressing any fear in the constitutional changes that I'm proposing.
I am trying to avoid some outcomes that I think are less desirable, but
that's simply because I think they're both possible to anticipate and not
desireable and I would like to prevent them for the same reasons that I
want to find and remove bugs from a computer program. I don't experience
that internally as fear.
>> I think the constitution is the wrong foundational document to look to
>> for the "minds of the governed." The constitution is concerned
>> primarily with the procedural details. We have to spell them out
>> somewhere so that we have a shared basis to make hard decisions in a
>> way that we've previously agreed would be fair (even if we're on the
>> losing side).
> Why focus solely on the defeat?
I mentioned the "losing side" part because that's the part of this process
that makes me the most happy. Being comfortable with an outcome that
doesn't match my preferences because I believe in the process that was
followed is something that brings me joy. To me, this is a key part of
what it means to be part of a community. It's an expression of solidarity
and mutual support to agree with my fellow community members on a fair
process, to follow that process even when it's difficult to do so because
it's leading to an outcome that isn't my preference, and to recognize that
accepting outcomes I don't agree with is part of living in a community.
It's easy to be part of a community when everyone agrees. It's powerful
and delightful to be part of a community when people disagree but the
community still works together with respect and mutual support. Creating
process that allows myself and others to do this more easily is part of
how I enjoy contributing to a community.
> The constitution's projection of hardened confrontation entails a
> terrible reflexivity: A 3:1 supermajority leaves no gray area. There is
> no gentle nudge and no room for measurement. The maintainer was so
> wrong, fixing it required the second-worst measure in the Debian
> universe.
I hear you that you perceive it that way, but I do not perceive it that
way *at all*. To me, part of being a member of Debian is knowing that the
project can overrule me, and being overruled by a 3:1 majority is
something that I think would be a powerful learning experience. It's
exactly moments like that from which I learn the most.
What makes those moments more emotionally negative for me is if they're
exceptionally rare and postponed until they become emergencies and are
thus full of pent-up emotion and years of frustration. That not only adds
considerably to the emotional weight, it prolongs the period in which I
might be investing time and resources into something the project does not
want.
I would love to be overruled so that I can learn. I want to be overruled
*quickly* so that I can course-correct sooner and learn faster. I don't
want to pursue a course of action for a year, three years, five years, and
*then* be overruled, on something the project could have overruled me on
in the first month, far more productively.
I therefore would love to make that process easier to start and more
frequent because I would love to get that sort of feedback from the
project more often.
That said, I don't believe this proposal does that; I think these changes
are entirely unrelated to one's opinion on that, and by themselves will
not make maintainer overrules either more or less likely.
> Procedural safeguards do not build consensus—the all-elusive
> project-wide goal the constitution so decidedly disavows.
I'm not sure that I agree with this. I think it's easier to reach
consensus when people don't feel backed into a corner. Psychologically,
the fewer options people feel like they have, the more defensive they
often become. The purpose of procedural safeguards is to give people
clear options so that they know exactly what they can do and can't do.
That can be calming; it can make people feel more comfortable exploring
consensus because they know they have a right to a more formal procedure
that they can keep in their back pocket, so to speak, and that can't be
taken away from them.
This was exactly the problem during some of the GR processes that this
proposal attempts to fix: because people felt like they were vulnerable to
procedural maneuvering, they had an incentive to be more absolute in their
positions to ensure that they wouldn't be outmaneuvered. When the
procedure is less fraught and more predictable, the process can be less
tense which creates more psychological space for exploration of ideas and
consensus-seeking.
That said, it's also true that I don't think a project the size of Debian
can run solely by consensus and am not particularly worried by the
project's willingness to make decisions via mechanisms other than
consensus when consensus isn't forthcoming. I think there is a great deal
of real-world political experience that shows consensus is very hard to
scale, and I have some personal experience with on-line governance that
makes me dubious of large communities that rely *solely* on consensus. My
experience is that this overemphasis on consensus as the only legitimate
decision-making process tends towards extreme conservatism, tedious
discussion, stagnation, loss of interest, and slow dissolution of the
community because the level of effort required to achieve anything is
judged to be too high.
> In another example of reflexivity, strong rules are a sign of conflict.
> They are not needed—and rarely adopted—in peaceful and easy-going
> communities.
I think it depends a great deal on the nature of the strong rules (and
partly on the definition of "strong"). I can think of rule sets that lead
to that outcome and could be described as strong, but they're rule sets
that centralize power in the hands of a few, make it difficult for anyone
other than the ruling coalition to start formal processes, or skew
outcomes towards those who already have power. In other words, it's less
the *strength* of the rules than the *fairness* of the rules that creates
those problems.
In contrast, it's hard to imagine a stronger rule set than a written
program, which describes to a computer exactly what to do and leaves as
little ambiguity as possible. But I find computer programs relaxing and
enjoyable precisely because of that predictability. The rules fade into
the background and I can build creative, beautiful, and exciting things on
top of those rules without having to worry that the foundation is
unstable.
>> My experience in multiple heated debates in Debian, and in similar
>> problems in other governance debates and on-line communities, is that
>> having good, clear, and previously-agreed process is exactly what
>> creates the space for people to be gracious and collaborative even when
>> they strongly disagree with the opinions of others.
> Please do not read my response as second-guessing your experience. I am
> simply using this "space ... to be gracious and collaborative even"
> though I "strongly disagree with the opinions of others".
Oh, absolutely! Your message was wonderful and I greatly appreciate your
thoughts and perspective.
>> But I think the net long-term effect is to reduce the temperature.
> How has it worked out so far?
I'm sure there will be a wide variety of opinions about this, but speaking
only for myself, I think it's worked quite well! In the places where we
have good decision-making processes and have used them, I think we've had
more clarity and more forward momentum, which in turn has made it easier
to enjoy working on Debian.
Where I personally have the most regrets is the number of places where
we've let necessary decisions go unmade for years. Emotions build up,
people start connecting their sense of self with support of a specific
side, people who would have worked on implementing any of the possible
decisions get demoralized by not having clear direction and stop working
on that area entirely, and then when we're finally forced to make a
decision, the decision carries far too much weight and becomes
overwhelming.
I would love for us to make more decisions, more quickly, and be more
willing to change them later based on further experience. I would love
for us to make more mistakes and learn from them, instead of being
unwilling to commit or to risk making anyone unhappy and thus postpone
decisions until they're no longer exciting or motivating and have become
mere drudgery.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: