Felix Lechner <felix.lech...@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 <r...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
