Re: Draft proposal for resolution process changes

[Russ Allbery <rra@debian.org>]

Richard Laager <rlaager@debian.org> writes:

> One concern I have about eliminating the 2:1 majority for a GR to
> make/override a TC decision is that it might encourage things to move to
> a GR unnecessarily.

> A second is that it might encourage things to move to a GR too
> soon. Having the TC hear something and hash out options in a smaller
> group setting seems useful, even if the issue ultimately ends up at a
> GR.

One minor clarification: I was thinking about removing the 2:1 *override*
requirement, but I don't think we should remove the 2:1 *make*
requirement.  In other words, I think it's valuable to go through the TC
first for technical decisions because the process hopefully involves
everyone writing things down and some good technical discussion led by TC
members, which would help improve the subsequent GR (if needed)
enormously.

It's after the TC have made a decision that I'm not sure the 2:1 majority
makes sense.  (Also by that point I'm not sure it's likely there would be
unnecessary GRs.  If people are generally happy with the TC decision, it
seems unlikely a GR would result.)

There's some weirdness here with maintainer overrides.  I'm not sure if it
should be possible to override a maintainer with a simple majority GR.
(By that, I mean I'm literally not sure; I can see arguments either way.)

> A way to split the difference might be to lift the 2:1 supermajority
> requirement under some conditions. For example: GR _options_ put forward
> by the TC do not have the 2:1 supermajority. So the TC could initiate a
> GR and say: these are the two or three options we think are reasonable,
> we should choose one of them, but we deadlocked on which one. As long as
> the Developers are choosing between those options, the majority decides
> (because getting _a_ decision is the goal). But if the developers choose
> to exercise their right to add alternatives and (attempt to) overrule
> the TC, then those alternatives must gain a supermajority of Developers.

> Here is a specific textual proposal:

>     4. Make or override any decision authorised by the powers of the
>     Technical Committee, provided they agree with a 2:1 majority. If
>     such a resolution has ballot options proposed by the Technical
>     Committee, those options do not need a 2:1 majority.

My first reaction is that this feels a little finnicky and perhaps too
complex.  But I'm still thinking about it and would love to hear other
opinions.

> I'm hesitant to make a TC tie automatically turn into a GR. If the
> options are really similar, varying in some detail, that should not
> trigger a GR. That's a waste of the Developers time and energy.

Yes, this is also one of my concerns.

> If we _really_ want to deal with the corner case of the TC chair having a
> casting vote when they are being overruled (which as I think about it is
> probably not that big of deal in practice),

Unless someone feels very strongly about this, I'm going to leave it alone
in my proposal because it's such a rare and obscure edge case that I doubt
that it will come up in my lifetime.  The existing solution is a little
weird, but it doesn't seem egregiously wrong, and it doesn't feel like
something we should spend energy on.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>