Re: GR Ballot Option: Allow, but do not require, secret voting

[Harlan Lieberman-Berg]

On Thu, Mar 3, 2022 at 3:12 AM Judit Foglszinger  wrote:
> I think, 4K puts the bar very high (that would require 20 people).

On Fri, Mar 4, 2022 at 12:39 PM Bill Blough  wrote:
> However, to generate further discussion, I do agree with Judit [1] that
> 4K seems like a high bar.

Hi Judit, Bill,

I agree, 4K is high.  I struggled with this a bit before I proposed
it, and I'm still not 100% sure it's the right balance, but this is
some of my thought process:

Unlike "regular" ballot options, a ballot option containing a vote for
secrecy is a final decision once it reaches the threshold.  It does
/not/ require voting to have an effect; rather, the mere existence of
a ballot option requesting secret ballots with 4K seconds will fix the
election to be a secret ballot, regardless of the outcome of the final
vote.  Even if zero people voted it above NOTA, it still would turn
the election into a secret ballot.

In this way, it feels to me like it should have a higher bar than what
is regularly required to propose a ballot option (K).  Looking at the
constitution, there are two other thresholds dictated about voting:
enough to put a decision on hold (2K = 10), or the quorum required for
a vote to be valid (3Q, approximately 48 people at the time of this
writing).

Because the constitution clearly wants to maintain a minimum threshold
for discussion of ballot options (i.e., setting K as the floor of Q or
5), I didn't want to use Q as a basis for this threshold.  It seemed
wrong to set it to 2K, though, considering that 2K developers merely
puts a decision on hold -- the final vote is what determines the
actual outcome.  Because this ballot option is itself a mini-vote
inside a vote (as it has an independent effect regardless of the vote
outcome), I decided it should be higher than 2K.

Why 4 and not 3?  I don't have a great logic for it.  I looked at
recent votes and counted the number of overall seconds between all
proposals, and set it based on that number to be high enough so I
thought it was realistically achievable, though a high bar.

In practice, the way that I would like to see this work is that a
ballot option is proposed with no content other than turning the
ballot to a secret option.  Then people can, regardless of their
position on the issue, second that ballot option to avoid splitting
the vote.  This would have been easily achievable on the RMS GR (n=47
unique seconds + proposers) and on the systemd GR (n=42 unique seconds
+ proposers), but not on the less controversial declassify debian
private vote (n=18 unique seconds + proposers).

I still hope that this option receives enough seconds to go on the
ballot as an intermediary position between the current options of
"always secret" and "never secret except for DPL elections".

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Re: Alternative: only make vote tally available to DD (or to voters)

[Holger Levsen]

Hi Bill,

On Fri, Mar 04, 2022 at 07:36:02PM +0100, Bill Allombert wrote:
> A suggestion:
> 
> An alternative to secret vote would be to make the vote tallies only
> accessible by DD (or more generally to people allowed to vote, whether
> they did not not).
> 
> This would still allow voters to check the vote but would not allow
> outside parties to use it (unless some DD leaks it, alas).
 
I guess people might sponsor this, so please reword this into an actual
proposal for the vote. I'm not sure I'll sponsor it but I think the option
should be on the table.

:) & thanks.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

:wq


signature.asc
Description: PGP signature

Re: GR Ballot Option: (first draft) No change to voting, recommend against GR for non-technical issues

[Holger Levsen]

hi Bill,

On Fri, Mar 04, 2022 at 04:12:44PM +0100, Bill Allombert wrote:
> > Anyway, how do we proceed here?
> We should merge them! Maybe you could suggest a new wording ?

given that my proposal already showed up on
https://www.debian.org/vote/2022/vote_001#textc could I please ask you
(or anybody else) to look at what's missing compared to your proposal?

(sorry to play the lazy card here. you're welcome to draw one as well :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The climate crisis makes a minimum voting age of 18 look so extremely unfair.


signature.asc
Description: PGP signature

General resolution: voting secrecy

[Kurt Roeckx]

Hi,

A general resolution about voting secrecy has been started. Details about
it are available at: https://www.debian.org/vote/2022/vote_001


Kurt Roeckx
Debian Project Secretary



signature.asc
Description: PGP signature

Debian Project Leader Elections 2022: Call for nominations

[Debian Project Secretary - Kurt Roeckx]

Hi,

According to the constitution (5.2. Appointment), project
leader elections should begin "six weeks before the leadership
post becomes vacant, or (if it is too late already) immediately."

The new project leader term starts on 2022-04-21. The time line
looks like:

| Period | Start   | End   |
|+-+---|
| Nomination | Saturday 2022-03-05 | Friday 2022-03-11 |
| Campaign   | Saturday 2022-03-12 | Friday 2022-04-01 |
| Vote   | Saturday 2022-04-02 | Friday 2022-04-15 |

Prospective leaders should be familiar with the constitution, but
just to review: there's a one week period when interested
developers can nominate themselves and announce their platform,
followed by a three week period intended for campaigning, followed
by two weeks for the election itself.

I intend to collect platform statements from the candidates, and
publish them at http://www.debian.org/vote/2022/platforms/ at the
end of the nomination period, which means around 2022-03-12.

I suggest that the candidates send the platform, preferably in
wml or HTML, to the secretary at least a day before the
publication date.

The format of the web page is open to discussion, but I suggest
there be at least three sections:
- Introduction / Biography
- Major Goal / Meat of the platform
- Rebuttal.

The candidates can make a rebuttal.  I would like to receive them
in the first week of the campaign period, so I can publish them
around 2022-03-20.

Details and results for the vote will be published at:
http://www.debian.org/vote/2022/vote_002

Please make sure that nominations are sent to (or cc:'d to)
debian-vote, and are cryptographically signed.


Kurt Roeckx
Debian Project Secretary



signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Stefano Rivera]

Hi Holger (2022.03.04_10:42:51_+)
> And then, early 2022 is not the time for rushed changes like this, which
> is also why I explicitly want to see "keep the status quo" on the ballot,
> and not only as "NOTA", but as a real option. 

If we were to have such an option on the ballot, my understanding of
constitution 4.2.4 is that we'd have both "keep the status quo" and
"NOTA" as ballot options.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: Reaffirm public voting

[Bill Allombert]

On Fri, Mar 04, 2022 at 04:24:46PM +0100, Stéphane Glondu wrote:
> Hello,
> 
> Le 04/03/2022 à 11:42, Holger Levsen a écrit :
> > The GR proposal for secret voting is silent on implenentation details,
> > probably because secret and transparent voting is, well, impossible to
> > achieve fully, [...]
> 
> It is possible to achieve some reasonable level of secrecy and
> transparency (and verifiability)... it is an active research topic per
> se. Belenios came out of this research, devotee-ng could also benefit
> from this research.
> 
> Disclaimer: I am upstream of Belenios in my dayjob.

I have voted several time using Belenios. This is probably the most
advanced free software voting solution. This has been useful to lots
of organisation during the lockdown.

However I feel this GR is putting the cart before the horses.
Before voting for or against a new voting system, we need to experiment
with them and see how they can be made to fit Debian. The secrecy used
for DPL elections is too weak if the purpose is to protect against
contentious GR.

That is why my own ballot proposal just say to keep the vote as is for
the time being and to discourage non-technical contentious GR.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

voting secrecy GR

[Kurt Roeckx]

Hi,

I've put up an initial page about the GR at:
https://www.debian.org/vote/2022/vote_001

I didn't have time yet to properly record all the seconds yet, but
believe the 3 option there all have the required amount of seconds,
and are the only options that reached that. The 3rd option reached
that today, updating the discussion period.


Kurt

Re: Amendment to GR Option 1: Hide Identities of Developers Casting a Particular Vote

[Russ Allbery]

Kurt Roeckx  writes:

> So reading A.1.4 again, I can also see it as just saying that it really
> updates when the period is over. I think it would have just been more
> clear if A.1.1 said "The initial discussion period is 2 weeks."

Agreed.  I'm sorry that I missed that.

-- 
Russ Allbery (r...@debian.org)  

Re: Amendment to GR Option 1: Hide Identities of Developers Casting a Particular Vote

[Kurt Roeckx]

On Fri, Mar 04, 2022 at 11:54:19AM -0800, Russ Allbery wrote:
> Kurt Roeckx  writes:
> 
> > I've been reading our new constitution about the discussion period. What
> > I find is this in A.1.1:
> > The discussion period starts when a draft resolution is proposed and
> > sponsored. The minimum discussion period is 2 weeks. The maximum
> > discussion period is 3 weeks.
> 
> > And in A.1.4:
> > The addition of a ballot option or the change via an amendment of a
> > ballot option changes the end of the discussion period to be one
> > week from when that action was done [...]
> 
> > As I see it, there is only a minimum and a maximum, but not some
> > default. After it's over, the secretary just call for vote. My
> > interpretation is that as long as the minimum and maximum is not the
> > same, the secretary can declare that the period is over after the
> > minimum is over, but can also wait until the maximum is over before
> > declaring it's over.
> 
> > So I can actually already say when the voting period is going to be,
> > and am going for Saturday 2022-03-19 to Friday 2022-04-01, which will
> > then directly be followed by the DPL vote.
> 
> Interesting.  That was certainly not my intent when I wrote it (which
> doesn't mean that it's necessarily wrong).  The intent was to explicitly
> set the end of the discussion period to match the minimum discussion
> period at the start of the process, and then have the end of the
> discussion period vary according to A.1.4 up to the maximum.  I agree that
> I seem to have left out a sentence explicitly saying that, though.  (I
> think there may have been one in an earlier draft that was lost in
> subsequent editing.)
> 
> Regardless of whether that was my intent, at first glance I don't mind
> your interpretation.  It wasn't what I had intended, but it seems like a
> fairly reasonable system.

So reading A.1.4 again, I can also see it as just saying that it really
updates when the period is over. I think it would have just been more
clear if A.1.1 said "The initial discussion period is 2 weeks."


Kurt

Re: Amendment to GR Option 1: Hide Identities of Developers Casting a Particular Vote

[Kurt Roeckx]

On Fri, Mar 04, 2022 at 01:12:23PM -0700, Sam Hartman wrote:
> One easy way for you to do that would be to send a diff to the spacing.
> I could then update my branch and use  the typo correction procedure in
> the constitution to get this fixed.

Or we can just leave it to the maintainer of the document to fix it.


Kurt

Re: Amendment to GR Option 1: Hide Identities of Developers Casting a Particular Vote

[Sam Hartman]

> "Ansgar" == Ansgar   writes:

Ansgar> Would removing the trailing space introduced by these
Ansgar> changes require a separate GR?  There are also other similar
Ansgar> inconsistencies, e.g., one space vs. two spaces after a
Ansgar> period.

There are a number of cases where you ask questions that really come
across as if you're trying to make others look stupid, or point out
flaws in the system or flaws in someone else's approach.

I regret that I got the spacing wrong.
The way I interact with the world, it's fairly difficult for me to know
where spaces are.
I think it would come across a lot less if you were trying to humiliate
others and instead come across as cooperative if rather than focusing on
what would happen if we didn't fix the spacing, if you focused on
helping try to fix the spacing.
One easy way for you to do that would be to send a diff to the spacing.
I could then update my branch and use  the typo correction procedure in
the constitution to get this fixed.

--Sam


signature.asc
Description: PGP signature

Re: Alternative: only make vote tally available to DD (or to voters)

[Lucas Nussbaum]

Hi,

On 04/03/22 at 19:36 +0100, Bill Allombert wrote:
> A suggestion:
> 
> An alternative to secret vote would be to make the vote tallies only
> accessible by DD (or more generally to people allowed to vote, whether
> they did not not).
> 
> This would still allow voters to check the vote but would not allow
> outside parties to use it (unless some DD leaks it, alas).

I believe that's a useful compromise, and I would second this option.

Lucas

Re: Amendment to GR Option 1: Hide Identities of Developers Casting a Particular Vote

[Russ Allbery]

Kurt Roeckx  writes:

> I've been reading our new constitution about the discussion period. What
> I find is this in A.1.1:
> The discussion period starts when a draft resolution is proposed and
> sponsored. The minimum discussion period is 2 weeks. The maximum
> discussion period is 3 weeks.

> And in A.1.4:
> The addition of a ballot option or the change via an amendment of a
> ballot option changes the end of the discussion period to be one
> week from when that action was done [...]

> As I see it, there is only a minimum and a maximum, but not some
> default. After it's over, the secretary just call for vote. My
> interpretation is that as long as the minimum and maximum is not the
> same, the secretary can declare that the period is over after the
> minimum is over, but can also wait until the maximum is over before
> declaring it's over.

> So I can actually already say when the voting period is going to be,
> and am going for Saturday 2022-03-19 to Friday 2022-04-01, which will
> then directly be followed by the DPL vote.

Interesting.  That was certainly not my intent when I wrote it (which
doesn't mean that it's necessarily wrong).  The intent was to explicitly
set the end of the discussion period to match the minimum discussion
period at the start of the process, and then have the end of the
discussion period vary according to A.1.4 up to the maximum.  I agree that
I seem to have left out a sentence explicitly saying that, though.  (I
think there may have been one in an earlier draft that was lost in
subsequent editing.)

Regardless of whether that was my intent, at first glance I don't mind
your interpretation.  It wasn't what I had intended, but it seems like a
fairly reasonable system.

-- 
Russ Allbery (r...@debian.org)  

Re: Amendment to GR Option 1: Hide Identities of Developers Casting a Particular Vote

[Kurt Roeckx]

On Thu, Mar 03, 2022 at 01:54:36PM -0700, Sam Hartman wrote:
> 
> I also believe this advances the end of the discussion period to next
> Thursday (although other actions may advance the end of the discussion
> period further).

I've been reading our new constitution about the discussion period. What
I find is this in A.1.1:
The discussion period starts when a draft resolution is proposed and
sponsored. The minimum discussion period is 2 weeks. The maximum
discussion period is 3 weeks.

And in A.1.4:
The addition of a ballot option or the change via an amendment of a
ballot option changes the end of the discussion period to be one
week from when that action was done [...]

As I see it, there is only a minimum and a maximum, but not some
default. After it's over, the secretary just call for vote. My
interpretation is that as long as the minimum and maximum is not the
same, the secretary can declare that the period is over after the
minimum is over, but can also wait until the maximum is over before
declaring it's over.

So I can actually already say when the voting period is going to be,
and am going for Saturday 2022-03-19 to Friday 2022-04-01, which will
then directly be followed by the DPL vote.


Kurt

Alternative: only make vote tally available to DD (or to voters)

[Bill Allombert]

A suggestion:

An alternative to secret vote would be to make the vote tallies only
accessible by DD (or more generally to people allowed to vote, whether
they did not not).

This would still allow voters to check the vote but would not allow
outside parties to use it (unless some DD leaks it, alas).

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Reaffirm public voting

[Bill Allombert]

On Fri, Mar 04, 2022 at 04:24:46PM +0100, Stéphane Glondu wrote:
> > A voting system which is transparent only to some, is undemocratic and
> > will lead to few people in the know, which is diagonal to Debians goals
> > of openness and transparency.
> 
> I'm not sure what you mean here. From some point of view, TLS is also
> transparent "only to some", since very few people understand the
> mathematics behind the crypto involved there. Yet, we don't promote
> unsecured communications where a TLS-secured variant exists.

TLS is not a voting system, so it does not need to have the same
property to be useful.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Amendment to GR Option 1: Hide Identities of Developers Casting a Particular Vote

[Ansgar]

On Thu, 2022-03-03 at 13:54 -0700, Sam Hartman wrote:
>   The next two weeks are the polling period during which
>   Developers may cast their votes. [-Votes in leadership elections
> are-]
> [-  kept secret, even after the election is finished.-]{++}

The unified diff for this looks like:

-  Developers may cast their votes.  Votes in leadership elections are
-  kept secret, even after the election is finished.
+  Developers may cast their votes. 

The change introduces a trailing space.

The GR specifically states:

| The developers resolve to make the changes to the Debian Constitution
| embodied in git commit ed88a1e3c1fc367ee89620a73047d84a797c9a1d.

Would removing the trailing space introduced by these changes require a
separate GR?  There are also other similar inconsistencies, e.g., one
space vs. two spaces after a period.

Ansgar, noting that "noone" and "no one" also differ only in (more
significant) whitespace

Re: GR Ballot Option: Allow, but do not require, secret voting

[Bill Blough]

I second the ballot option quoted below.

However, to generate further discussion, I do agree with Judit [1] that
4K seems like a high bar.

In a general sense, if the bar is too high then the result might be
indistinguishable from not allowing secret votes at all. Of course the
opposite could be true as well - if the bar is too low, then it might be
indistinguishable from having all votes be secret.

Is 4K too high?  Or is it high but still OK?  Would K or 2K be more
appropriate?  Or would those be too low?  I honestly don't know.

If the goal is to default to openness, but still allow secret votes
for sensitive topics, how do we choose the threshold that is best suited
to that?

Best regards,
Bill

[1] https://lists.debian.org/debian-vote/2022/03/msg00016.html

On Tue, Mar 01, 2022 at 11:13:03PM -0500, Harlan Lieberman-Berg wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hello everyone,
> 
> I propose the following ballot option for the current GR:
> 
> Rationale
> 
> While I agree that there are some votes which, due to their nature,
> may be so controversial that the potential for a person's votes to be
> publicly revealed may cause them to change their vote (or opt out of
> the election), even among divisive GRs, few rise to that level of
> controversy: the RMS GR and the systemd GR being two recent examples
> which have provoked ire.
> 
> There is something which fundamentally distinguishes the kind of
> voting that Debian does from that of a private institution or group,
> where minutes and votes are typically kept out of public view: Debian
> serves a larger community than the members of the institution.  In
> that sense, we are more similar to a public body than a private
> membership.
> 
> Our Social Contract makes this distinction clear: when it says that we
> will not hide problems, it immediately emphasizes that the bug
> database will be open for public view at all times.   Taking the step
> to make a particular vote secret should require us to stop and
> carefully weigh the costs to the larger community.
> 
> I hope this option better strikes the balance between the aspirations
> of public visibility and the occasional, pragmatic need for secrecy.
> 
> Ballot Option
> ==
> The changes are available at:
> https://salsa.debian.org/hlieberman/webwml/-/commit/82729d07aba7dd7ac641f7e4a87178f34b23efca
> 
> A diff follows (the word diff is very confusing, so I've omitted it):
> 
> diff --git a/english/devel/constitution.wml b/english/devel/constitution.wml
> index 41cb9dfbd80..7924992d3a7 100644
> - --- a/english/devel/constitution.wml
> +++ b/english/devel/constitution.wml
> @@ -226,12 +226,15 @@ earlier can overrule everyone listed later.
> 
>
>  
> - -   Votes are taken by the Project Secretary. Votes, tallies, and
> - -   results are not revealed during the voting period; after the
> - -   vote the Project Secretary lists all the votes cast. The voting
> - -   period is 2 weeks, but may be varied by up to 1 week by the
> - -   Project Leader.
> +   Votes, tallies, and results are not revealed during the voting period.
> +   After the vote, the Project Secretary lists all the votes cast, unless
> +   either one of the following is true:
>  
> +
> +   The vote is for a leadership election as defined in
> §5.2.
> +   At least 4K Developers have sponsored any single ballot option
> +   which says the votes will be kept secret.
> +
>
> 
>
> 
> 
> - --
> Harlan Lieberman-Berg
> ~hlieberman
> -BEGIN PGP SIGNATURE-
> 
> iQKTBAEBCgB9FiEELyAgabIlUqb16FUfGikbTg3OS1cFAmIe7pJfFIAALgAo
> aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDJG
> MjAyMDY5QjIyNTUyQTZGNUU4NTUxRjFBMjkxQjRFMERDRTRCNTcACgkQGikbTg3O
> S1d5zQ/9F9rMHgeOnEyXWkZ1gIAabwjzY5IedPkoEGECaGz9uiYA446J/Q+jH5V6
> blDNcTmy3VL8YxrPJ1NKhwYpF7SCL0QxUnCXiFtp5UFYzCiDWqWGHM4UbqPMZxox
> 8Z3/oDu7W5N8aa9GHSsL0f6aHtxBHxIS/CnA+wtOIGuGEpHQRxGhqQ0P17pbPkDn
> bOMbPC9x2Sve2bwzZ4hlvCySRGVorwKNWsvjZ7LWCc5k6a1ZLBYFQK065J6l17NN
> 6+rEBZ8yJ6UHnQ9wH1Y7loM8B4Z35qgf6MwXyeqMYHSRSrmfAc2uIp/EL4FStig2
> 4wWiNEyN6QuWkR75Tr3ZSNC+2NF3ptRmM+gc2nBWhz6Zx+yVm5JmvRHkGQfsTrRD
> 0NtVTflHIOHGsFHYj16IHmC1Xvu/9OHvf4bQumahIG88Rz58Zgsi965FaDTRn5di
> FtAxKoxsqzvKAe0OJkUHOnSVnv3w95UNg0uco5tgbUmDYISlFYNTHav0gL1EQBR2
> GeNYNlJP6zlFEu6uxZuXlfv3BLNvQ4Yc2miE9Rv14bKEd1QizPVUGpX5YR8a89Ph
> QF2tSdy62MFqRrV9VKmheEnNb2uNsttFJci6ZBjci32zP6mMMFEgUuvgfl2CaMbG
> MUBi7dtjYkoL3IQuj+OsF5VKZLq2ERJhIDf8mogzetUWNT8aQVo=
> =5e/l
> -END PGP SIGNATURE-
> 

-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Gunnar Wolf]

Jean-Philippe MENGUAL dijo [Fri, Mar 04, 2022 at 01:08:33PM +0100]:
> Hi,
> 
> I think we can establish a limitation between "secret" and "wiser
> secret". I can understand that making vote transparent and secret is
> likely not possible. And I am not sure that it is the purpose. The
> purpose is not to see displayed on a public website one name related
> to a GR and a vote.

An idea just floated to me :-) The reason our GRs are called General
Resolutions and not, ahem, "votes" (except when we talk about them
informally or want to write in fewer characters) is IMO because Debian
works as a collective, where we held assemblies, and collectively
discuss, propose and choose among options.

Assemblies are often open (in real-world gatherings). People
argue. When it comes to voting, you know what to expect about most of
the people (those you know best, and those that did the arguing).

Votes come from electoral systems, from larger constituencies. The
stakes are different, yes, but the _participation style_ is also
different. And I think we should remain closer to an assembly than to
an electoral system.

Yes, Debian has grown a lot since our Constitution was
drafted. However, I joined in 2003, approximately where the amount of
DDs stabilized; we have been ~800-1100 people since then. The model
has worked decently for the past twenty years; we had two cases where
private voting could have allowed people to express their opinions
without fear of hate-mail, retaliation or somesuch (the FSF and the
systemd votes, both with a strong political rather than technical
component, even though systemd _is_ technical).

> In other words, while I dont think someone will do a detailed
> investigation to know who voted what (most people just will not want
> to spend energy for this), anyone, including with malicious purpose,
> can visit a web page to see what I voted and do harasment
> then.
>
> While I accept not to be in a full secret, as I am not afraid with
> persons who can do harasment to spend so energy to find this info in
> a deep server or via a hash or whatever, I am worry bif any mad guy
> can see what I voted about a GR as I know the person will not
> hesitate to attack me. Again, we have an example of this, of high
> flame, during RMS GR, and while the most radical persons probably
> did not want to do deep investigations about voters, I think they
> were ready to visit a page and go after voters. I dont know if it
> happent effectively, but given how the vote happent with trials to
> disturb after the campaign time, it is possible.

Voting is a single-time action. If somebody is willing to harass
people with strong viewpoints... It's much easier IMO to go through
the mailing list archives and find who is more active, and not only
find their vote, but their full argumentation. Votes for the most part
_cannot_ really be private for the people most involved in a decision
if we are consistent with our argumentation.

Of course, you argue just the other way, that people will attack us
based on the vote tally. But we are talking -and you expressly
recognize it- about what _could_ happen, not about what _has_
happened.

> The last thing which may justify a such ballot is the idea that "if you dont
> want to see your name related to a vote, just dont vote, you dont have to do
> it, you are free". this may be acceptable for political GRs, but more a
> problem for ambiguous situations.
> 
> Hence the importance to make secret possible at least, if not general and
> mandatory.

I agree votes should be "secretizable". But I really hope they don't
become mandatorily secret.


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Gunnar Wolf]

I know Holger's and Bill's proposed options are prone to change and
merge, but I'll say it now and probably reaffirm it later:

I second this option.

While I prefer Harlan's, it has failed to gain sponsors, and I don't
want to risk the complete loss of public votes in Debian. I think the
status quo (all votes are public except for DPL votes) is much better
than the other proposals.

Holger Levsen dijo [Fri, Mar 04, 2022 at 10:42:51AM +]:
> Reaffirm public voting
> ==
> 
> Since we can either have secret and intransparent voting, or we can have
> open and transparent voting, the project resolves to leave our voting
> system as it is.
> 
> Rationale:
> 
> The GR proposal for secret voting is silent on implenentation details,
> probably because secret and transparent voting is, well, impossible to
> achieve fully, so this GR is bound to a similar fate as the 'publish 
> debian-private' vote, which was voted for and then was never implemented.
> 
> A voting system which is transparent only to some, is undemocratic and
> will lead to few people in the know, which is diagonal to Debians goals
> of openness and transparency.
> 
> And then, early 2022 is not the time for rushed changes like this, which
> is also why I explicitly want to see "keep the status quo" on the ballot,
> and not only as "NOTA", but as a real option. 
> 
> I'm seeking sponsors for this amendment to the current GR.



-- 



signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Stéphane Glondu]

Hello,

Le 04/03/2022 à 11:42, Holger Levsen a écrit :
> The GR proposal for secret voting is silent on implenentation details,
> probably because secret and transparent voting is, well, impossible to
> achieve fully, [...]

It is possible to achieve some reasonable level of secrecy and
transparency (and verifiability)... it is an active research topic per
se. Belenios came out of this research, devotee-ng could also benefit
from this research.

Disclaimer: I am upstream of Belenios in my dayjob.

> A voting system which is transparent only to some, is undemocratic and
> will lead to few people in the know, which is diagonal to Debians goals
> of openness and transparency.

I'm not sure what you mean here. From some point of view, TLS is also
transparent "only to some", since very few people understand the
mathematics behind the crypto involved there. Yet, we don't promote
unsecured communications where a TLS-secured variant exists.


Cheers,

-- 
Stéphane

Re: GR Ballot Option: (first draft) No change to voting, recommend against GR for non-technical issues

[Bill Allombert]

On Fri, Mar 04, 2022 at 12:21:04PM +, Holger Levsen wrote:
> hi Bill,
> 
> On Thu, Mar 03, 2022 at 12:10:53AM +0100, Bill Allombert wrote:
> > Ballot Option
> > =
> > 
> > 1) The Debian project decide against changing its voting process at this
> > time.
> > 
> > 2) General resolutions that probe developpers opinions about non-technical 
> > issues 
> > outside the social contract are discouraged.
> > 
> > Rationale
> > =
> > 
> > So far no voting scheme that preserve both the integrity of the vote and
> > the secret of the vote have been proposed. The scheme used for DPL
> > election does not provide plausible deniability.
> > 
> > 2. is not made a hard requirement so that it need not be adjudicated by
> > the Debian secretary. However most of the developers that seconded the first
> > ballot of GR 2021_002 were experienced developers that would be have been
> > able to heed the recommendation given in this GR.
> 
> seems I missed your ballot proposal when I suggested mine in 
> https://lists.debian.org/debian-vote/2022/03/msg00021.html
> (Message-id: yihtkywt2lhdl...@layer-acht.org>), I'm sorry and I'm blaming
> information overload everywhere, which is why I'm behind in catching up on
> reading @-vote.

> Anyway, how do we proceed here?

We should merge them! Maybe you could suggest a new wording ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Christian Kastner]

On 2022-03-04 13:15, Holger Levsen wrote:
> On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott Bécue wrote:
>> Is init systems GR a political GR?
> 
> yet there are people maintaining systemd and sysv in public.

How is that relevant?

I'm neither a systemd nor sysv maintainer, but considering the grief
that some other non-maintainers got just for expressing that they favor
systemd, I'd rather not vote at all if it's not secret.

You of all people should know this. You've spoken out against exactly
this kind of grief. You asked for a shield back then, and that's what
the people in favor of voting secrecy are asking for now.

Best,
Christian

Re: Reaffirm public voting

[Santiago Ruano Rincón]

El 04/03/22 a las 12:03, Mattia Rizzolo escribió:
> On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:
> > Reaffirm public voting
> > ==
> > 
> > Since we can either have secret and intransparent voting, or we can have
> > open and transparent voting, the project resolves to leave our voting
> > system as it is.
> > 
> > Rationale:
> > 
> > The GR proposal for secret voting is silent on implenentation details,
> > probably because secret and transparent voting is, well, impossible to
> > achieve fully, so this GR is bound to a similar fate as the 'publish 
> > debian-private' vote, which was voted for and then was never implemented.
> > 
> > A voting system which is transparent only to some, is undemocratic and
> > will lead to few people in the know, which is diagonal to Debians goals
> > of openness and transparency.
> > 
> > And then, early 2022 is not the time for rushed changes like this, which
> > is also why I explicitly want to see "keep the status quo" on the ballot,
> > and not only as "NOTA", but as a real option. 
> > 
> > I'm seeking sponsors for this amendment to the current GR.
> 
> 
> Assuming you meant this as "this ballot" instead of "this amendment"
> (following the new GR flow), I sponsor this.
> 
> 

I sponsor this ballot.

> If I were to add my thoughts: political GRs don't belong in Debian,
> please take them elsewhere.  For non-political votes there is no use
> for private voting.

I think technical is political. Giving freedom to software users is
political.
And I'd rather say we should avoid GRs involving individuals.

Cheeers,

 -- S


signature.asc
Description: PGP signature

Re: GR Ballot Option: (first draft) No change to voting, recommend against GR for non-technical issues

[Mathias Behrle]

* Bill Allombert: " GR Ballot Option: (first draft) No change to voting,
  recommend against GR for non-technical issues" (Thu, 3 Mar 2022 00:10:53
  +0100):

> Dear developers,
> 
> I propose the following ballot option for the current GR:
> 
> Ballot Option
> =
> 
> 1) The Debian project decide against changing its voting process at this
> time.
> 
> 2) General resolutions that probe developpers opinions about non-technical
> issues outside the social contract are discouraged.
> 
> Rationale
> =
> 
> So far no voting scheme that preserve both the integrity of the vote and
> the secret of the vote have been proposed. The scheme used for DPL
> election does not provide plausible deniability.
> 
> 2. is not made a hard requirement so that it need not be adjudicated by
> the Debian secretary. However most of the developers that seconded the first
> ballot of GR 2021_002 were experienced developers that would be have been
> able to heed the recommendation given in this GR.
> 
> Respectfully submitted,

FTR I am sponsoring this. Whatever Bill and Holger decide about their similar
options.

-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6


pgpI42JbWPVyu.pgp
Description: Digitale Signatur von OpenPGP

Re: Reaffirm public voting

[Mathias Behrle]

* Philip Hands: " Re: Reaffirm public voting" (Fri, 04 Mar 2022 13:23:32 +0100):

> Holger Levsen  writes:
> 
> > On Fri, Mar 04, 2022 at 12:03:22PM +0100, Mattia Rizzolo wrote:  
> >> On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:  
> >> > Reaffirm public voting
> >> > ==
> >> > 
> >> > Since we can either have secret and intransparent voting, or we can have
> >> > open and transparent voting, the project resolves to leave our voting
> >> > system as it is.
> >> > 
> >> > Rationale:
> >> > 
> >> > The GR proposal for secret voting is silent on implenentation details,
> >> > probably because secret and transparent voting is, well, impossible to
> >> > achieve fully, so this GR is bound to a similar fate as the 'publish 
> >> > debian-private' vote, which was voted for and then was never implemented.
> >> > 
> >> > A voting system which is transparent only to some, is undemocratic and
> >> > will lead to few people in the know, which is diagonal to Debians goals
> >> > of openness and transparency.
> >> > 
> >> > And then, early 2022 is not the time for rushed changes like this, which
> >> > is also why I explicitly want to see "keep the status quo" on the ballot,
> >> > and not only as "NOTA", but as a real option. 
> >> > 
> >> > I'm seeking sponsors for this amendment to the current GR.  
> >> Assuming you meant this as "this ballot" instead of "this amendment"
> >> (following the new GR flow), I sponsor this.  
> >
> > yes, that's what I ment, thanks. Do I need to resent my mail now with this
> > change? :)  
> 
> I sponsor this.
> 
> While I may not end up voting for it as my first option, I think it
> deserves to be an explicit option, because I can imagine that no
> super-majority emerges in this vote, and if that happens then we will be
> able to draw rather different conclusions about the project consensus
> depending upon whether this option comes above or below NotA (and by how
> much).
> 
> Cheers, Phil.

I sponsor this as well.


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6


pgpIZjIS7Pa98.pgp
Description: Digitale Signatur von OpenPGP

Re: Reaffirm public voting

[Philip Hands]

Holger Levsen  writes:

> On Fri, Mar 04, 2022 at 12:03:22PM +0100, Mattia Rizzolo wrote:
>> On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:
>> > Reaffirm public voting
>> > ==
>> > 
>> > Since we can either have secret and intransparent voting, or we can have
>> > open and transparent voting, the project resolves to leave our voting
>> > system as it is.
>> > 
>> > Rationale:
>> > 
>> > The GR proposal for secret voting is silent on implenentation details,
>> > probably because secret and transparent voting is, well, impossible to
>> > achieve fully, so this GR is bound to a similar fate as the 'publish 
>> > debian-private' vote, which was voted for and then was never implemented.
>> > 
>> > A voting system which is transparent only to some, is undemocratic and
>> > will lead to few people in the know, which is diagonal to Debians goals
>> > of openness and transparency.
>> > 
>> > And then, early 2022 is not the time for rushed changes like this, which
>> > is also why I explicitly want to see "keep the status quo" on the ballot,
>> > and not only as "NOTA", but as a real option. 
>> > 
>> > I'm seeking sponsors for this amendment to the current GR.
>> Assuming you meant this as "this ballot" instead of "this amendment"
>> (following the new GR flow), I sponsor this.
>
> yes, that's what I ment, thanks. Do I need to resent my mail now with this
> change? :)

I sponsor this.

While I may not end up voting for it as my first option, I think it
deserves to be an explicit option, because I can imagine that no
super-majority emerges in this vote, and if that happens then we will be
able to draw rather different conclusions about the project consensus
depending upon whether this option comes above or below NotA (and by how
much).

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: GR Ballot Option: (first draft) No change to voting, recommend against GR for non-technical issues

[Holger Levsen]

hi Bill,

On Thu, Mar 03, 2022 at 12:10:53AM +0100, Bill Allombert wrote:
> Ballot Option
> =
> 
> 1) The Debian project decide against changing its voting process at this
> time.
> 
> 2) General resolutions that probe developpers opinions about non-technical 
> issues 
> outside the social contract are discouraged.
> 
> Rationale
> =
> 
> So far no voting scheme that preserve both the integrity of the vote and
> the secret of the vote have been proposed. The scheme used for DPL
> election does not provide plausible deniability.
> 
> 2. is not made a hard requirement so that it need not be adjudicated by
> the Debian secretary. However most of the developers that seconded the first
> ballot of GR 2021_002 were experienced developers that would be have been
> able to heed the recommendation given in this GR.

seems I missed your ballot proposal when I suggested mine in 
https://lists.debian.org/debian-vote/2022/03/msg00021.html
(Message-id: yihtkywt2lhdl...@layer-acht.org>), I'm sorry and I'm blaming
information overload everywhere, which is why I'm behind in catching up on
reading @-vote.

Anyway, how do we proceed here?

For now, I'm also seconding your proposal.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

In Europe there are people prosecuted by courts because they saved other people
from drowning in the  Mediterranean Sea.  That is almost as absurd  as if there
were people being prosecuted because they save humans from drowning in the sea.


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Mattia Rizzolo]

On Fri, Mar 04, 2022 at 06:41:54AM -0500, Tiago Bortoletto Vaz wrote:
> On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott Bécue wrote:
> > I'm pretty sure some gave double thoughts before voting because of the
> > shitstorm/flame that had happened before the vote.
> 
> This has been argued already it seems.

Yes, it's already been discussed, I doubt it needs to be discussed even
more here, and I surely don't want to.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Holger Levsen]

On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott Bécue wrote:
> Is init systems GR a political GR?

yet there are people maintaining systemd and sysv in public.
so what's next, secret maintainers?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

This is a pandemic, not a war. People keep dying even if you surrender.


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Jean-Philippe MENGUAL]

Hi,

I think we can establish a limitation between "secret" and "wiser 
secret". I can understand that making vote transparent and secret is 
likely not possible. And I am not sure that it is the purpose. The 
purpose is not to see displayed on a public website one name related to 
a GR and a vote. In other words, while I dont think someone will do a 
detailed investigation to know who voted what (most people just will not 
want to spend energy for this), anyone, including with malicious 
purpose, can visit a web page to see what I voted and do harasment then. 
While I accept not to be in a full secret, as I am not afraid with 
persons who can do harasment to spend so energy to find this info in a 
deep server or via a hash or whatever, I am worry bif any mad guy can 
see what I voted about a GR as I know the person will not hesitate to 
attack me. Again, we have an example of this, of high flame, during RMS 
GR, and while the most radical persons probably did not want to do deep 
investigations about voters, I think they were ready to visit a page and 
go after voters. I dont know if it happent effectively, but given how 
the vote happent with trials to disturb after the campaign time, it is 
possible.


The last thing which may justify a such ballot is the idea that "if you 
dont want to see your name related to a vote, just dont vote, you dont 
have to do it, you are free". this may be acceptable for political GRs, 
but more a problem for ambiguous situations.


Hence the importance to make secret possible at least, if not general 
and mandatory.


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 04/03/2022 à 12:41, Tiago Bortoletto Vaz a écrit :

On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott Bécue wrote:


Mattia Rizzolo  wrote on 04/03/2022 at 12:03:22+0100:


[[PGP Signed Part:Signature made by expired key 0816B9E18C762BAD Mattia Rizzolo 
  ]]
On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:

Reaffirm public voting
==

Since we can either have secret and intransparent voting, or we can have
open and transparent voting, the project resolves to leave our voting
system as it is.

Rationale:

The GR proposal for secret voting is silent on implenentation details,
probably because secret and transparent voting is, well, impossible to
achieve fully, so this GR is bound to a similar fate as the 'publish
debian-private' vote, which was voted for and then was never implemented.

A voting system which is transparent only to some, is undemocratic and
will lead to few people in the know, which is diagonal to Debians goals
of openness and transparency.

And then, early 2022 is not the time for rushed changes like this, which
is also why I explicitly want to see "keep the status quo" on the ballot,
and not only as "NOTA", but as a real option.

I'm seeking sponsors for this amendment to the current GR.



Assuming you meant this as "this ballot" instead of "this amendment"
(following the new GR flow), I sponsor this.



If I were to add my thoughts: political GRs don't belong in Debian,
please take them elsewhere.  For non-political votes there is no use
for private voting.


Is init systems GR a political GR?

I'm pretty sure some gave double thoughts before voting because of the
shitstorm/flame that had happened before the vote.


Not only that, but also conflicts of interest involving an employer may
have influence over a non-political vote (or the willingness to vote).
This has been argued already it seems.

Bests,

--
Tiago

Re: Reaffirm public voting

[Tiago Bortoletto Vaz]

On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott Bécue wrote:
> 
> Mattia Rizzolo  wrote on 04/03/2022 at 12:03:22+0100:
> 
> > [[PGP Signed Part:Signature made by expired key 0816B9E18C762BAD Mattia 
> > Rizzolo   ]]
> > On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:
> >> Reaffirm public voting
> >> ==
> >> 
> >> Since we can either have secret and intransparent voting, or we can have
> >> open and transparent voting, the project resolves to leave our voting
> >> system as it is.
> >> 
> >> Rationale:
> >> 
> >> The GR proposal for secret voting is silent on implenentation details,
> >> probably because secret and transparent voting is, well, impossible to
> >> achieve fully, so this GR is bound to a similar fate as the 'publish 
> >> debian-private' vote, which was voted for and then was never implemented.
> >> 
> >> A voting system which is transparent only to some, is undemocratic and
> >> will lead to few people in the know, which is diagonal to Debians goals
> >> of openness and transparency.
> >> 
> >> And then, early 2022 is not the time for rushed changes like this, which
> >> is also why I explicitly want to see "keep the status quo" on the ballot,
> >> and not only as "NOTA", but as a real option. 
> >> 
> >> I'm seeking sponsors for this amendment to the current GR.
> >
> >
> > Assuming you meant this as "this ballot" instead of "this amendment"
> > (following the new GR flow), I sponsor this.
> >
> >
> >
> > If I were to add my thoughts: political GRs don't belong in Debian,
> > please take them elsewhere.  For non-political votes there is no use
> > for private voting.
> 
> Is init systems GR a political GR?
> 
> I'm pretty sure some gave double thoughts before voting because of the
> shitstorm/flame that had happened before the vote.

Not only that, but also conflicts of interest involving an employer may
have influence over a non-political vote (or the willingness to vote).
This has been argued already it seems.

Bests,

--
Tiago

Re: Reaffirm public voting

[Pierre-Elliott Bécue]

Mattia Rizzolo  wrote on 04/03/2022 at 12:03:22+0100:

> [[PGP Signed Part:Signature made by expired key 0816B9E18C762BAD Mattia 
> Rizzolo   ]]
> On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:
>> Reaffirm public voting
>> ==
>> 
>> Since we can either have secret and intransparent voting, or we can have
>> open and transparent voting, the project resolves to leave our voting
>> system as it is.
>> 
>> Rationale:
>> 
>> The GR proposal for secret voting is silent on implenentation details,
>> probably because secret and transparent voting is, well, impossible to
>> achieve fully, so this GR is bound to a similar fate as the 'publish 
>> debian-private' vote, which was voted for and then was never implemented.
>> 
>> A voting system which is transparent only to some, is undemocratic and
>> will lead to few people in the know, which is diagonal to Debians goals
>> of openness and transparency.
>> 
>> And then, early 2022 is not the time for rushed changes like this, which
>> is also why I explicitly want to see "keep the status quo" on the ballot,
>> and not only as "NOTA", but as a real option. 
>> 
>> I'm seeking sponsors for this amendment to the current GR.
>
>
> Assuming you meant this as "this ballot" instead of "this amendment"
> (following the new GR flow), I sponsor this.
>
>
>
> If I were to add my thoughts: political GRs don't belong in Debian,
> please take them elsewhere.  For non-political votes there is no use
> for private voting.

Is init systems GR a political GR?

I'm pretty sure some gave double thoughts before voting because of the
shitstorm/flame that had happened before the vote.
-- 
PEB


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Holger Levsen]

On Fri, Mar 04, 2022 at 12:03:22PM +0100, Mattia Rizzolo wrote:
> On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:
> > Reaffirm public voting
> > ==
> > 
> > Since we can either have secret and intransparent voting, or we can have
> > open and transparent voting, the project resolves to leave our voting
> > system as it is.
> > 
> > Rationale:
> > 
> > The GR proposal for secret voting is silent on implenentation details,
> > probably because secret and transparent voting is, well, impossible to
> > achieve fully, so this GR is bound to a similar fate as the 'publish 
> > debian-private' vote, which was voted for and then was never implemented.
> > 
> > A voting system which is transparent only to some, is undemocratic and
> > will lead to few people in the know, which is diagonal to Debians goals
> > of openness and transparency.
> > 
> > And then, early 2022 is not the time for rushed changes like this, which
> > is also why I explicitly want to see "keep the status quo" on the ballot,
> > and not only as "NOTA", but as a real option. 
> > 
> > I'm seeking sponsors for this amendment to the current GR.
> Assuming you meant this as "this ballot" instead of "this amendment"
> (following the new GR flow), I sponsor this.

yes, that's what I ment, thanks. Do I need to resent my mail now with this
change? :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

We live in a world where teenagers get more and more desperate trying to
convince adults to behave like grown ups.


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Mattia Rizzolo]

On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote:
> Reaffirm public voting
> ==
> 
> Since we can either have secret and intransparent voting, or we can have
> open and transparent voting, the project resolves to leave our voting
> system as it is.
> 
> Rationale:
> 
> The GR proposal for secret voting is silent on implenentation details,
> probably because secret and transparent voting is, well, impossible to
> achieve fully, so this GR is bound to a similar fate as the 'publish 
> debian-private' vote, which was voted for and then was never implemented.
> 
> A voting system which is transparent only to some, is undemocratic and
> will lead to few people in the know, which is diagonal to Debians goals
> of openness and transparency.
> 
> And then, early 2022 is not the time for rushed changes like this, which
> is also why I explicitly want to see "keep the status quo" on the ballot,
> and not only as "NOTA", but as a real option. 
> 
> I'm seeking sponsors for this amendment to the current GR.


Assuming you meant this as "this ballot" instead of "this amendment"
(following the new GR flow), I sponsor this.



If I were to add my thoughts: political GRs don't belong in Debian,
please take them elsewhere.  For non-political votes there is no use
for private voting.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Reaffirm public voting

[Holger Levsen]

Reaffirm public voting
==

Since we can either have secret and intransparent voting, or we can have
open and transparent voting, the project resolves to leave our voting
system as it is.

Rationale:

The GR proposal for secret voting is silent on implenentation details,
probably because secret and transparent voting is, well, impossible to
achieve fully, so this GR is bound to a similar fate as the 'publish 
debian-private' vote, which was voted for and then was never implemented.

A voting system which is transparent only to some, is undemocratic and
will lead to few people in the know, which is diagonal to Debians goals
of openness and transparency.

And then, early 2022 is not the time for rushed changes like this, which
is also why I explicitly want to see "keep the status quo" on the ballot,
and not only as "NOTA", but as a real option. 

I'm seeking sponsors for this amendment to the current GR.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The vision of self driving cars is nothing compared to the vision of no cars
at all.


signature.asc
Description: PGP signature

Re: Amendment to GR Option 1: Hide Identities of Developers Casting a Particular Vote

[Pierre-Elliott Bécue]

Hi,

I'm still happy with sponsoring the following ballot option.

Sam Hartman  wrote on 03/03/2022 at 21:54:36+0100:

> [[PGP Signed Part:No public key for 2C6C4C3CA8378674 created at 
> 2022-03-03T21:54:36+0100 using EDDSA]]
>
> I hereby amend the ballot option I proposed using the procedure in
> Constitution section A.1.  My understanding is that this amendment
> replaces my ballot option unless one of the sponsors objects.
> There are two changes.  The first is the change to rationale I sent out
> yesterday.  The second is to insert a newline between the General
> Resolution title and the following line of '=' characters.
>
>
> I also believe this advances the end of the discussion period to next
> Thursday (although other actions may advance the end of the discussion
> period further).
>
> 
>
> Rationale
> =
>
> During the vote for GR_2021_002, several developers said they were
> uncomfortable voting because under the process at that time, their name
> and ballot ranking would be public.
> A number of participants in the discussion believe that we would get
> election results that more accurately reflect the will of the developers
> if we do not make the name associated with a particular vote on the
> tally sheet public.
> Several people believed that the ranked votes without names attached
> would still be valuable public information.
>
> This proposal would treat all elections like DPL elections.
> At the same time it relaxes the requirement that the secretary must
> conduct a vote via email.  If the requirement for email voting is
> removed, then an experiment is planned at least with the belenios voting
> system [1]. belenios may provide better voter secrecy and an easier
> web-based voting system than our current email approach.
> If this proposal passes, adopting such an alternative
> would require sufficient support in the project but would not require
> another constitutional amendment.
>
> [1]: https://lists.debian.org/yhotrixtz3aip...@roeckx.be
>
> This proposal increases our reliance on the secretary's existing power
> to decide how votes are conducted.  The lack of an override mechanism
> for secretary decisions about how we conduct votes has not been a
> problem so far.  However, if we are going to rely on this power to
> consider questions like whether the project has sufficient consensus to
> adopt an alternate voting mechanism, we need an override mechanism.
> So, this proposal introduces such a mechanism.
>
> Summary of Changes
> ==
>
> 1) Do not make the identity of a voter casting a particular vote
> public.
>
> 2) Do not require that votes be conducted by email.
>
> 3) Clarify that the developers can replace the secretary at any time.
>
> 4) Provide a procedure for overriding the decision of the project
> secretary or their delegate.  Overriding the decision of what super
> majority is required or overriding the determination of election
> outcome requires a 3:1 majority.  The chair of the technical committee
> decides who conducts such votes.
>
> 6) Codify that our election system must permit independent verification
> of the outcome given the votes cast and must permit developers to
> confirm their vote is included in the votes cast.
>
> General Resolution
> ==
>
> The developers resolve to make the changes to the Debian Constitution
> embodied in git commit ed88a1e3c1fc367ee89620a73047d84a797c9a1d.
> As of February 23, 2022, this commit can be found at
> https://salsa.debian.org/hartmans/webwml/-/commit/ed88a1e3c1fc367ee89620a73047d84a797c9a1d
>
> For convenience a word-diff of the changes is included below.  In case
> the diff differs from the commit, the commit governs.
>
> @@ -179,9 +179,27 @@ earlier can overrule everyone listed later.
>   
>
>   
> [-In case of-]{+Appoint+} a [-disagreement between-]{+new secretary.
> In the normal case ( §7.2) where+} the project
> leader and {+secretary agree on+} the [-incumbent-]{+next+} secretary,
> [-appoint a new secretary.-]{+this power of+}
> {+the developers is not used.+}
>   
>   {++}
> {+Override a decision of the project secretary or their+}
> {+delegate.+}
>
> {+Overriding the determination of what super majority is required+}
> {+for a particular ballot option or overriding the determination of+}
> {+the outcome of an election requires the developers to agree by a+}
> {+3:1 majority.  The determination of the majority required to+}
> {+override a decision of the secretary is not subject to+}
> {+override.+}
>
> {+The chair of the technical committee decides who acts as+}
> {+secretary for a general resolution to override a decision of the+}
> {+project secretary or their delegate. If the decision was not made+}
> {+by the chair of the technical committee, the committee chair may+}
> {+themselves act as secretary. The decision of wh