Re: Second Round: Informal Discussion of Proposal to Hide Identities of Developers Casting a Particular Vote
I'm generally happy with this proposed text. Just a couple of pieces of
feedback, one quite minor.
Sam Hartman <hartmans@debian.org> writes:
> {+ identity of a developer casting a particular vote is not made+}
> {+ public, but developers will be given an option to confirm their vote is included in the votes+} cast. The voting period is 2 weeks, but may be varied by up
Maybe "mechanism" rather than "option"? Option implies to me that it
might be some sort of up-front choice the voter has to make.
More substantively, while I agree with being able to override the Project
Secretary via GR, I'm less comfortable with being able to put Project
Secretary decisions on hold if the GR is sponsored by 2K developers. That
feels like a potential procedural mess. Is there any way that we could do
without that and only allow retroactive overrides, or in some other way
clarify just *what* happens if a secretarial decision is put on hold?
Here's the sort of situation that I'm worried about:
* Some GR is proposed and is discussed for a couple of weeks.
* Near the end of the discussion period, the Project Secretary says that
this vote requires a 3:1 majority.
* Some developers disagree and propose a GR to override that decision.
* That GR gets 2K sponsors.
Now, under this new text, the Project Secretary's decision is "put on
hold." However, the constitution requires that the Project Secretary
start a vote on the GR because its discussion period has ended. So what
does putting that decision on hold *mean*? Does it mean we hold the vote
saying that it's a 1:1 majority?
This gets even murkier if the Project Secretary makes a decision that
isn't a binary choice. I don't think this specific scenario is likely,
but what if someone objects to the Project Secretary's one-line summaries
for a ballot and successfully puts that decision on hold? What does "on
hold" even mean in that sort of context?
I realize this is really an objection to 4.2.2.2 in general, which is kind
of a mess, but at least it's currently a mess that's largely external to
our voting process, affecting decisions elsewhere in the project. I'm
worried that putting decisions on hold in the context of votes risks
getting into weird procedural edge cases where we cannot reasonably
proceed with a vote due to a pending override but are constitutionally
required to proceed with the vote.
I think I'd rather restrict overrides in the specific case of the Project
Secretary to not have the "on hold" provision, and absorb the potential
complexity of having to re-run votes with different parameters if the
resulting GR is successful.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: