Re: Second Round: Informal Discussion of Proposal to Hide Identities of Developers Casting a Particular Vote
Sam Hartman <hartmans@debian.org> writes:
>>>>>> "Russ" == Russ Allbery <rra@debian.org> writes:
> Russ> Maybe "mechanism" rather than "option"? Option implies to me
> Russ> that it might be some sort of up-front choice the voter has to
> Russ> make.
> But it is an up-front choice today.
> If you have an encryption subkey, you get to participate.
> If you don't then you do not.
> I used the word option specifically to capture that right now it is an
> up-front choice.
Oh, I see. This is fine with me, then.
> I don't think no matter how hard we try we will be able to resolve all
> the conflicts in the constitution, so I am more interested in making
> sure there are mechanisms to interpret and build up experience over time
> than to try and make sure things are unambiguous.
I agree. I would prefer to err on the side of empowering the Secretary to
make decisions in the moment (we can always redo GRs if we have to), and
am only nervous because we may have created a situation where we have a
deadlock the Secretary isn't empowered to break.
> Unfortunately, I think that just moves the problem around.
> Let's say there's no language talking about putting a decision on hold.
> What do we do if someone overrides the decision about what super
> majority is required ?
> We're still left with a mess.
To me, the critical points are that:
1. We need to have some sort of deadlock-free, starvation-free path to
resolving questions about a vote and then running that vote.
2. There's a reasonable argument for some way for the developers as a
whole to overrule or replace a Project Secretary. Right now, there's a
specific weird edge case where the Project Leader appoints the
Secretary and the Secretary runs the election of the Project Leader
(and the votes for every overrule of the Project Leader), so in theory
two people could collaborate to put the project in a very awkward spot.
> IN other words, I think we are exposing and acknowledging mesiness that
> was already inherent in the system.
Yes. All of these problems are pre-existing, so maybe this is really a
topic for a different GR. This comes up here specifically only because a
secret vote increases the required level of trust.
> Even with things like calling for the vote, I suspect that in practice a
> secretary would delay the vote while there was a discussion in full
> swing about some secretary decisions, text in the constitution not
> withstanding.
I suppose one possible narrow fix would be to amend A.3.1 to say that the
seven day limit is waived if Secretary decisions about the vote have been
put on hold.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: