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

Secret Ballots: Handling Disagreement with the Secretary





Hi, everyone.
Now that we have concluded deciding our GR procedure, I'd like to come
back to the question of secret ballots that we decided to defer from the
last round.
As a reminder, that discussion started at
https://lists.debian.org/tslilx2fuo8.fsf@suchdamage.org


In <87a6ic6wl1.fsf@arioch.leonhardt.eu>, Carsten LEONHARDT noted that in
addition to being suitable to the secretary, the manner in which votes
are cast needs to be suitable to the developers.

At the time, I proposed that one way to handle this would be to
introduce a mechanism for developers to override a decision of the
secretary.
That handles a more general problem than the one Carsten identified.
There are a couple of alternatives I can think about focused
specifically on the manner of voting, but I think solving the general
problem is good.

So, I propose to allow the voters to override a decision of the
secretary just as they can override the TC, the DPL, or the DPL's
delegates.

For most cases, I think it would be fine for the developers to override
by a simple majority.
There are two cases that stand out where I think that would be
inappropriate:

1) The secretary's determination of what super majority is required for
a particular ballot option.
Imagine someone proposing to "interpret" the DFSG as not actually
requiring source code for programs.  The secretary decides that's not so
much an interpretation of the DFSG as an actual change to the DFSG, and
thus requires a 3:1 super majority.
We wouldn't want to make it easier than 3:1 to decide that no, that's
really not a change, and thus only needs a simple majority.

2) The secretary's determination of election outcome.  I hope this never
gets overridden, but you could imagine cases where  there is a debate
about whether to count certain votes or the like.
Especially if any options on the ballot had super majorities, changing
the election shouldn't be easier than these super majorities.


I propose that both of these cases require a 3:1 super majority to
override the secretary.
(That is currently the highest super majority we require for anything
including changing the constitution.)

So, to be specific, I propose to add a paragraph 8 to section 4.1
(powers of the developers):

    8. Override a decision of the secretary. Overriding the secretary's
       determination of the majority required for a ballot option or
       overriding the determination of the outcome of a vote requires that
       the developers agree by a 3:1 majority. The secretary's
       determination of whether a 3:1 majority is required to override
       the project secretary is not itself subject to override.

I'd appreciate comments on this proposal and on the general issue.
Assuming the discussion resolves reasonably quickly, I propose to send
out a new version of the secret ballot proposal including a fix to this
issue in around a week.

Attachment: signature.asc
Description: PGP signature


Reply to: