Richard Laager <rlaa...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
