Re: Draft proposal for resolution process changes
Richard Laager <rlaager@debian.org> writes:
> First off, thank you for working on this!
> On 9/27/21 8:51 PM, Russ Allbery wrote:
>> 6. If voting is started prior to two weeks after the original proposal
>> via a call for a vote by a member of the Technical Committee, but
>> another member of the Technical Committee objects more than two
>> weeks after the original proposal but before the vote completes, the
>> vote is still canceled. All members of the Technical Committee are
>> then given 24 hours to add new ballot options or modify or withdraw
>> the ballot options they have proposed. During this period no one may
>> call for a vote. Following that 24 hour period, a new voting period
>> automatically starts and cannot be canceled.
> Is this complexity necessary? If the vote was not called early, the vote
> would have started anyway on time and been uncancellable. And the
> objector did not object in time. (If the objector had objected prior to
> the normal starting time, we aren't in this scenario.) Why does someone
> get extra time to object in this case?
I went back and forth on this. I can drop it if people don't think the
edge case is important enough.
The scenario where this matters is this:
1. Vote starts. There is some controversy and discussion for a week and a
half.
2. 12 days into the voting period one TC member is away or ill or
otherwise unable to immediately respond.
3. Another TC member calls a vote, possibly immediately after making some
last minute change to the ballot (which is allowed).
4. By the time the TC member who would object returns, either the timing
for the mandatory vote has elapsed or, were the vote canceled, the
mandatory vote would start again within a matter of hours.
Basically, there is a scenario where the vote could be canceled but the
subsequent ensuing discussion period during which members can change their
ballot options is so short as to be unfair (some of the committee is
asleep) or unusable.
In other words, what this provision is here for is that it provides a
significant disincentive for anyone to tactically start a vote at the last
minute to cut off the last day or two of discussion, possibly immediately
after making a ballot change. Under this provision, someone who disagrees
can wait until the two weeks have passed and then object and the
discusssion period is effectively extended by 24 hours, which will
hopefully give everyone a chance to react regardless of time zones.
I admit that this is a very obscure edge case and it's unlikely to be
triggered. I can drop it if people would prefer the simplicity and are
willing to live with that scenario on the grounds that everyone should get
their preferred options in reasonably far in advance of the known deadline
and last-minute changes to other people's options therefore shouldn't
matter all that much (and if they do, one can always vote further
discussion and start again).
We do need to say something about what happens if a vote is called before
the two-week deadline and then objected to after the two-week deadline,
since otherwise the rules are ambiguous. We could say something simpler,
though, such as "An ongoing vote cannot be canceled if more than two weeks
have passed since the original proposal."
>> 2. Details regarding voting.
>> 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
>> (unless they are the Chair, in which case they may use only their
>> casting vote).
> I know this is how it is now. But it's always seemed weird. If TC members
> cannot vote on overruling themselves, why does the chair get to (but only
> in the event of a tie)?
I think we need to avoid an undefined outcome, so if there is no casting
vote, we have to pick some other strategy for making the outcome defined.
The only alternatives that I can think of are picking the result randomly
among the Schwartz set with no defeats, or declaring further discussion
the winner, but both of those have problems. (Or, I guess a third would
be to give a casting vote to someone outside the TC, like the DPL, but I'm
not sure if that additional complexity is worth it.)
I think the former is fine for selecting the chair; obviously both
candidates have support and I think a random choice is a reasonable
outcome of that ballot. But choosing between two very technical decisions
at random just feels wrong to me.
The latter may sound more reasonable, but the problem is that the tie
could be between multiple options that are nothing like further
discussion, and both of which beat further discussion by substantial
margins, so the winner is then the least-favored option, which seems
backwards. Maybe that's what we want, but that isn't obvious to me.
> Is this even meaningful? Presumably they would vote against overruling
> themselves, if there are such options. But it seems that if they don't
> vote, the measure would fail anyway? Or is this more about them choosing
> between multiple options (possibly all of which overrule themselves)?
One piece that you may be missing here is that the default option is
special. It's been a while since I worked out the details, but I'm fairly
sure one implication of A.6.3 is that the default option cannot be part of
a Schwartz set with other options, because by definition of the Schwartz
set those other options cannot have beaten the default option, and
therefore they would have been dropped under A.6.3. So this is always a
case of selecting from some set of options other than the default option.
Now, depending on how those options are drafted, that doesn't mean that
all the options would overrule the Chair. But it does mean that the vote
is a bit more complicated than an up-down vote on a single option.
Given the supermajority requirement for overrulling a developer, I think
the chances are high that if we ever end up in this scenario, the Chair
would be choosing between multiple overrule options.
>> 1. Options which do not have an explicit supermajority requirement have a
>> 1:1 majority requirement. The default option must not have any
>> supermajority requirements.
> "must not" or "does not"?
Changed to "does not."
>> 2. The votes are counted according to the rules in A.6. The default option
>> is "None of the above," unless specified otherwise.
> This "None of the above" seems duplicative of the one above. Do we need
> both?
Good point, we can now drop the default because it's fully specified
everywhere. Done in my draft.
>> When the vote counting mechanism of the Standard Resolution Procedure is
>> to be used, the text which refers to it must specify who has a casting
>> vote, the quorum, the default option, and any supermajority requirement.
> Maybe the "The default option must not have any supermajority
> requirements." should be moved here?
Good idea. Done.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: