Re: Draft proposal for resolution process changes
Thank you so much for the kind words, Bdale. I echo Sam's gratitude for
your work helping Debian make decisions. I couldn't have said it better.
Bdale Garbee <bdale@gag.com> writes:
> FWIW, the idea that any TC vote so evenly split that a casting vote
> might be required by the chair should instead transition to a GR is
> growing on me.
I've been thinking about this because I like the idea in theory but can't
see how to make it work in the process without introducing new problems
including tactical voting issues. I have also been wondering why it would
be necessary for the constitution to say this given that anyone can start
a GR and could choose to start a GR in this case. In other words, why
does the GR need to be forced, as opposed to an option that a TC member or
any other Developer can exercise?
That led me to point 4.1.4, which I think may be closer to the heart of
this problem than I'd realized:
Make or override any decision authorised by the powers of the
Technical Committee, provided they agree with a 2:1 majority.
I think the problem with the casting vote may be less that it was used and
more that it triggers this 2:1 majority requirement, which raises the bar
for a subsequent GR. We worked around this in the init system TC
decision, but that has to be done explicitly every time.
Thinking about this some more, I'm having a hard time imagining a
situation in which a majority of the developers via GR disagree with a TC
decision, and yet I would agree that the project should ignore that GR and
proceed with the TC decision. In other words, even beyond the issue of a
casting vote, I'm not sure we want this 2:1 majority requirement at all.
I can guess at the reasons why this constitutional provision is currently
there: stability of decisions (so once a decision is made it's harder to
overturn than to make, creating a ratchet of stability), and an attempt to
avoid making technical decisions by GR, which has some obvious issues.
However, I'm not sure we've had problems with either decision instability
or excessive eagerness to make technical decisions by GR, and I'm more
worried about issues simmering in frustration rather than being clearly
decided because people hesitate to bring a GR or think it would be a waste
of time. I'm also worried that this 2:1 majority may make the TC less
willing to make decisions that are before them because they feel "too
powerful," although I know there is huge disagreement within the project
about how many decisions the TC should make.
In short, I'm wondering if we should remove this 2:1 majority requirement
and if that would then remedy the concern about using the casting vote
rather than punting the issue to a GR. The project can then take into
account the narrowness of the TC decision when deciding whether to decide
it by GR instead.
That said, I'm also a bit leery of oversolving one specific TC problem
because it's so vivid in our minds, even though we've made or are making
subsequent procedural changes. This proposal would already change how
issues are brought to a vote, and combined with hindsight and other social
changes in the project since, it's possible we've already addressed the
relevant problems and may now be piling on too many untested changes. But
that's a minor concern, and the 2:1 majority for TC overrides does seem
odd to me.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: