[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Second Round: Informal Discussion of Proposal to Hide Identities of Developers Casting a Particular Vote



TL;DR: I propose to unbundle  the idea of putting secretary decisions
on-hold from my proposal.
I believe that will resolve Russ's concern.

>>>>> "Russ" == Russ Allbery <rra@debian.org> writes:

    Russ> Yes.  All of these problems are pre-existing, so maybe this is
    Russ> really a topic for a different GR.  This comes up here
    Russ> specifically only because a secret vote increases the required
    Russ> level of trust.

I find the idea that we should only make the changes necessary for
secret ballots in this GR compelling.
So, my plan in terms of what I propose will be to remove the text about
putting secretary decisions on hold.
I think we're both agreed that we are unlikely to need that for
overriding decisions about the voting system.

If someone else proposed a version with the text about putting secretary
decisions on-hold, I'd sponsor it  and depending on how some of the
corner cases we're talking about here get resolved, possibly rank it
above the version I'm proposing.

However, I'm trying to come up with something that appeals to the
broadest set of people who want secret ballots,
and I think that doesn't include the text about putting decisions on
hold.

Unless you're interested in debugging a version that does involve
putting secretary decisions on hold, stop reading here.

----------------------------------------

I've rearranged Russ's message significantly to focus on the open
issues.
Apologies if my cut&paste distorts meaning, although I tried to work
hard to avoid that.
    Russ>   I would prefer to err on the side of empowering the
    Russ> Secretary to make decisions in the moment (we can always redo
    Russ> GRs if we have to), and am only nervous because we may have
    Russ> created a situation where we have a deadlock the Secretary
    Russ> isn't empowered to break.

I think the secretary is always empowered to break a deadlock by their
power to interpret the constitution.


    Russ> To me, the critical points are that:

    Russ> 1. We need to have some sort of deadlock-free, starvation-free
    Russ> path to resolving questions about a vote and then running that
    Russ> vote.

I am not that concerned about deadlock-free, because I think that the
secretary will always find a way to break a deadlock.
However, your concern about starvation-free is one I share.
I'm imagining 2k developers not acting in good faith putting an endless
series of decisions on hold and blocking the entire process.


    Russ> 2. There's a reasonable argument for some way for the
    Russ> developers as a whole to overrule or replace a Project
    Russ> Secretary.  Right now, there's a specific weird edge case
    Russ> where the Project Leader appoints the Secretary and the
    Russ> Secretary runs the election of the Project Leader (and the
    Russ> votes for every overrule of the Project Leader), so in theory
    Russ> two people could collaborate to put the project in a very
    Russ> awkward spot.

I think the changes we're making do make it easier to replace the
secretary if necessary.

    >> 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.

    Russ> I suppose one possible narrow fix would be to amend A.3.1 to
    Russ> say that the seven day limit is waived if Secretary decisions
    Russ> about the vote have been put on hold.

I think that removes a deadlock but not starvation.
I think that a secretary would be likely to make that decision
regardless of what the constitution says,
but I agree that change would improve things if secretary decisions can
be put on hold.

Attachment: signature.asc
Description: PGP signature


Reply to: