Re: Draft proposal for resolution process changes
"Dr. Bas Wijnen" <wijnen@debian.org> writes:
> On Tue, Sep 28, 2021 at 04:11:44PM +0200, Karsten Merker wrote:
>> In case there should be consensus about requiring the TC chair to
>> provide a casting vote in case of a tie, this would IMHO require
>> changing the wording of clause 6.3.2.
> I agree that if we keep the casting vote intact, it needs to be a must
> in order to ensure the TC will always decide something. However, I agree
> with Adrian that it would be better to instead turn the decision into a
> GR in such a case.
My understanding of what you're proposing here is a boarder change where
the TC does not have a casting vote at all for any vote (not just for the
edge case of a vote to override a maintainer decision by the Chair), and
that if the Schwartz set has two or more members, the result is to not
make a decision?
Procedurally, I don't believe we should automatically start a GR because I
think there's benefit to going through the normal GR process. For
example, who is the proposer of the GR for the purposes of making
subsequent ballot option changes? This special type of GR would add a
bunch of complexity that we'd have to spell out, and I don't think it's
worth it. Given that any Developer can start a GR following such an
outcome, I think the way to achieve this if this is what we want is to
declare further discussion the winner in any ambiguous vote that would
otherwise be decided by casting vote and then leave it open whether
someone chooses to start a GR.
But before we decide this, it's worth remembering that the only way this
can arise is if the TC is split between two non-default decisions (so
there is consensus to make *some* decision), and the question (unlike the
one where the TC ended up split over init systems) may be urgent. A GR
takes a *minimum* of three more weeks, and most likely would take closer
to five.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: