I'm generally happy with this proposed text. Just a couple of pieces of feedback, one quite minor.
Sam Hartman <hartm...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>