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

Re: Secret Ballots: Handling Disagreement with the Secretary



Hi,

Personally I am not sure that the secretary needs a challenging process, given how he/she/they is chosen and how the general vote process works. However, when he/she/they needs to take a decision, it is because the constitution enables him/her/them to do it, for defined situations. The question of secret vote does not make part of them, if I remember correctly the constitution and the debate, so the debate was about intrepreting the text about this.

This matter is extremely important for me, as soon as Debian starts voting political/social GRs and not only technical ones. So I would like to focus on the secret vote instead of a general change of the secretary override, but it is just my feeling. I think that the vote should explicitly be secret, except a decision from the majority of the developers. It is really a GR I would like to see.

Regards,


Jean-Philippe MENGUAL
Debian Developer non uploading
Community team member
Accessibility team member
debian-l10n-french team member
President of Debian France non-profit organization

Le 29/01/2022 à 17:07, Sam Hartman a écrit :



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.


Reply to: