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.
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.
I was originally going to also limit this to _resolutions_ proposed by
the TC, but that seems unnecessary at best and undesirable at worst (as
someone could then try to tactically race the TC to change the status of
the TC ballot options).
I suppose there's a wrinkle regarding the default option ("None of the above"). It is also not subject to a supermajority, so it's possible that it could win over all options proposed by the TC. I guess that's the Developers saying to go back to the drawing board, and if that's what we prefer over any TC option, then I guess that's a useful result.
----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.
The Debian voting system is supposed to be cloneproof. We consider it desirable to be able to propose similar options varying in some detail. If that can lead to a GR, that could act as a disincentive to proposing slightly different options and/or tactical voting to avoid the undesirable GR.
Or potentially one person on the TC could force a GR by tactical voting when they wouldn't otherwise be able to do that by themselves.
I think I'd leave it as the chair has a casting vote. ----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), maybe this:
The Chair has a casting vote. When the Technical Committee votes whether to override a Developer who also happens to be a member of the Committee, that member may not vote. If that Developer is the Chair, the Project Leader has the casting vote instead. If the Project Leader is being overruled or there is no Project Leader, the Project Secretary has the casting vote instead. -- Richard
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature