Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.vote > #3063 > unrolled thread

Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public

Back to article view | Back to linux.debian.vote

Contents

  Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Sam Hartman <hartmans@debian.org> - 2022-02-13 22:30 +0100
    Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Sam Hartman <hartmans@debian.org> - 2022-02-13 23:10 +0100
      Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Russ Allbery <rra@debian.org> - 2022-02-14 04:00 +0100
    Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Don Armstrong <don@debian.org> - 2022-02-13 23:40 +0100
      Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Sam Hartman <hartmans@debian.org> - 2022-02-14 00:20 +0100
        Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Don Armstrong <don@debian.org> - 2022-02-15 00:50 +0100
      Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Felix Lechner <felix.lechner@lease-up.com> - 2022-02-14 01:40 +0100
        Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Russ Allbery <rra@debian.org> - 2022-02-14 04:10 +0100
      Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Sam Hartman <hartmans@debian.org> - 2022-02-14 17:00 +0100
        Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Karsten Merker <merker@debian.org> - 2022-02-14 21:30 +0100
        Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Richard Laager <rlaager@debian.org> - 2022-02-15 00:50 +0100
          Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Don Armstrong <don@debian.org> - 2022-02-15 01:30 +0100
            Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Russ Allbery <rra@debian.org> - 2022-02-15 01:40 +0100
              Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Philip Hands <phil@hands.com> - 2022-02-15 09:50 +0100
                Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Russ Allbery <rra@debian.org> - 2022-02-15 18:00 +0100
                  Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Felix Lechner <felix.lechner@lease-up.com> - 2022-02-16 00:00 +0100
                    Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Philip Hands <phil@hands.com> - 2022-02-16 09:20 +0100
                      Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Marc Haber <mh+debian-vote@zugschlus.de> - 2022-02-16 09:20 +0100
                      Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Russ Allbery <rra@debian.org> - 2022-02-16 18:00 +0100
                        Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Bdale Garbee <bdale@gag.com> - 2022-02-16 18:10 +0100
                        Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Russ Allbery <rra@debian.org> - 2022-02-16 20:30 +0100
                        Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Philip Hands <phil@hands.com> - 2022-02-16 20:30 +0100
                      Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Felix Lechner <felix.lechner@lease-up.com> - 2022-02-16 18:20 +0100
            Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Sam Hartman <hartmans@debian.org> - 2022-02-15 02:50 +0100
              Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Ansgar <ansgar@43-1.org> - 2022-02-15 10:30 +0100
                Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Russ Allbery <rra@debian.org> - 2022-02-15 17:40 +0100
                Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Gard Spreemann <gspr@nonempty.org> - 2022-02-16 13:30 +0100
                  Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Ansgar <ansgar@43-1.org> - 2022-02-16 18:30 +0100
                    Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Gard Spreemann <gspr@nonempty.org> - 2022-02-16 19:40 +0100
                    Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Gard Spreemann <gspr@nonempty.org> - 2022-02-16 19:50 +0100
        Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Bill Blough <bblough@debian.org> - 2022-02-17 07:10 +0100
      Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Bill Blough <bblough@debian.org> - 2022-02-17 07:10 +0100
        Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Sam Hartman <hartmans@suchdamage.org> - 2022-02-17 16:10 +0100
    Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Philip Hands <phil@hands.com> - 2022-02-14 10:40 +0100
      Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Thomas Goirand <zigo@debian.org> - 2022-02-14 12:10 +0100
        Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Jean-Philippe MENGUAL <jpmengual@debian.org> - 2022-02-14 12:30 +0100
          Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Gunnar Wolf <gwolf@debian.org> - 2022-02-17 17:40 +0100
        Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Antonio Terceiro <terceiro@debian.org> - 2022-02-14 14:10 +0100
          Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Philip Hands <phil@hands.com> - 2022-02-14 15:00 +0100
            Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Antonio Terceiro <terceiro@debian.org> - 2022-02-14 15:40 +0100
            Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Jean-Philippe MENGUAL <jpmengual@debian.org> - 2022-02-14 16:20 +0100
            Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Andrey Rahmatullin <wrar@debian.org> - 2022-02-14 16:20 +0100
            Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Stefano Rivera <stefanor@debian.org> - 2022-02-14 16:30 +0100
              Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Philip Hands <phil@hands.com> - 2022-02-14 16:50 +0100
                Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Russ Allbery <rra@debian.org> - 2022-02-14 18:10 +0100
            Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Felix Lechner <felix.lechner@lease-up.com> - 2022-02-14 19:50 +0100
              Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Felix Lechner <felix.lechner@lease-up.com> - 2022-02-14 22:40 +0100
              Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Steve McIntyre <steve@einval.com> - 2022-02-15 00:30 +0100
              Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Jonathan Carter <jcc@debian.org> - 2022-02-16 10:00 +0100
      Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Gunnar Wolf <gwolf@debian.org> - 2022-02-17 17:30 +0100
    Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Louis-Philippe Véronneau <pollo@debian.org> - 2022-02-14 19:50 +0100
    Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Stefano Rivera <stefanor@debian.org> - 2022-02-17 00:10 +0100
      Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Stefano Zacchiroli <zack@debian.org> - 2022-02-17 08:00 +0100
      Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Filippo Rusconi <lopippo@debian.org> - 2022-02-17 10:20 +0100
    Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Enrico Zini <enrico@enricozini.org> - 2022-02-17 10:20 +0100
      Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Steve McIntyre <steve@einval.com> - 2022-02-17 11:50 +0100
      Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Enrico Zini <enrico@enricozini.org> - 2022-02-17 21:10 +0100
    Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Antonio Terceiro <terceiro@debian.org> - 2022-02-17 12:40 +0100
    Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Guillem Jover <guillem@debian.org> - 2022-02-18 13:20 +0100
      Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Antonio Terceiro <terceiro@debian.org> - 2022-02-18 15:40 +0100
        Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public Judit Foglszinger <urbec@riseup.net> - 2022-02-18 16:40 +0100
          Re: Informal Discussion: Identities of Voters Casting a Particular  Ballot are No Longer Public Sam Hartman <hartmans@debian.org> - 2022-02-18 18:50 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#3063 — Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public

[Multipart message — attachments visible in raw view] — view raw

This starts informal discussion of a proposed general resolution to
amend the constitution.  I am not seeking sponsors at this time.
Comments including support or alternatives are welcome.  I think this is
mature enough to seek review from the secretary.

Rationale
=========

During the vote for GR_2021_002o, 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.  There are no current plans to move away from
email, although some members of the project want to explore
alternatives.  If this proposal passes, adopting such an alternative
would require sufficient support in the project but would not require
another constitutional amendment.

This proposal relies on the secretary's existing power to decide how
votes are conducted.  During discussion we realized that there is no
mechanism to override a specific decision of the secretary, and the
language allowing the project to replace the secretary is ambiguous.

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.


General Resolution==================

The developers resolve to make the changes to the Debian Constitution
embodied in git commit 030405434d040e14bbebebaeda64555b5c1ee16a.
As of February 13, 2022, this commit can be found at
https://salsa.debian.org/hartmans/webwml/-/commit/030405434d040e14bbebebaeda64555b5c1ee16a




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.</cite></p> </li>

  <li>
    [-<p>In case of-]{+<p>Appoint+} a [-disagreement between-]{+new secretary. In the normal case ( &sect;7.2) where+} the project
    leader and {+secretary agree on+} the [-incumbent-]{+next+} secretary, [-appoint a new secretary.</p>-]{+this power of+}
{+    the developers is not used.</p>+}
  </li>
  {+<li>+}
{+    <p>Override a decision of the project secretary or their+}
{+    delegate.</p>+}

{+    <p>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.</p>+}

{+    <p>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 who acts as secretary+}
{+    for such a general resolution is not subject to override.</p>+}
</ol>

<h3>4.2. Procedure</h3>
@@ -228,9 +246,10 @@ earlier can overrule everyone listed later.</cite></p>
    <p>
       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
       {+identity of a developer casting a particular vote is not made+}
{+       public. The+} voting period is 2 weeks, but may be varied by up
       to 1 week by the Project Leader. 
    </p>
  </li>

@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.</cite></p>
  </li>

  <li>
    <p>Votes are cast[-by email-] in a manner suitable to the Secretary.
    The Secretary determines for each poll whether voters can change
    their votes.</p>
  </li>
@@ -371,8 +390,7 @@ earlier can overrule everyone listed later.</cite></p>
  necessary.</li>

  <li>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.</li>-]{+</li>+}

  <li>The options on the ballot will be those candidates who have
  nominated themselves and have not yet withdrawn, plus None Of The

----------------------------------------
The diff does a completely horrid job of capturing the change to 4.1(7).
The new text for that paragraph is:
    Appoint a new secretary. In the normal case ( &sect;7.2) where the project
    leader and secretary agree on the next secretary, this power of
    the developers is not used.
    

[toc] | [next] | [standalone]

#3064

[Multipart message — attachments visible in raw view] — view raw

Russ, and others who cared about the issue.  I wanted to draw your
attention to how I'm proposing to approach who runs the vote for
secretary overrides.

In general I'm proposing that the chair of the TC make the decision of
who acts as secretary for that vote.
The rationale there is that they are the backup secretary for a number
of constitutional functions already.

I explicitly say that it is fine for them to conduct the vote if it's
not a vote to override their decision.
First, note if they are acting as secretary for some other reason
(secretary is absent without a delegation), it might be their decision
subject to override.

However, in many cases it will not be their decision, and since they are
the backup secretary it seems reasonable for them to conduct the vote.

I do not forbid the chair of the TC from decising that the secretary
conduct a vote to override the secretary's decision.
I actually think there may be some cases where it's generally agreed
that the secretary made a decision but doesn't have huge skin in the
game.


I also do not provide a way to override the decision of who conducts the
vote--not even when the TC chair is deciding who handles a vote to
override their own decision.
It can't be turtles all the way down or five developers could bring
everything to a grinding halt  proposing to override the person
overriding the override of the overriden override.
My hope is that especially in a situation where they are involved, the
TC Chair will seek input and wait until the project comes up with
someone very well respected who hasn't been involved.
If they fail to do that, I think replacing the secretary (and/or the TC
chair) is a better fix than overriding a single decision.

Here's my thinking on the entire matrix of issues here.

1) We could just fall back on being able to replace the secretary.  If
we don't like what they doing, remove them.
I think that's the wrong answer because:

2) The secretary already has a lot of power regarding how votes are
conducted.  This proposal emphasizes that.  It is already clear project
members want a clear voice on that.  So I want to give them a mechanism
to have that voice.  (There have been a couple of what to me appeared
controversial decisions of the secretary in the past: the decision
around the policy delegation and the decision on how the TC doesn't
interact with DPL delegated decisions, even when those decisions are
technical.)  I'll admit I've always been a bit uncomfortable that the
project had little recourse if it disagreed with the secretary there.

3) But I'm mostly imagining this mechanism to be used in cases where we
have a secretary who is working well, but a single decision needs review
by the project.
I think it is reasonable to trust everyone involved to be acting in what
they see as the project's best interest.
If there are doubts of that nature, I think changing staff is best.
So, I don't want to go over board with the paranoia.
That said, recent world politics have reminded me that sometimes these
corner cases around change of power matter.


Here are other options I could support:

* Explicitly say that you can never conduct a vote regarding overriding
  a decision you made.

* Introducing some mechanism to choose who conducts a vote to override a
  decision of the TC chair acting as secretary.  I don't know who to
  pick though; DPL is a bad choice because of their power to introduce a
  GR.

* Give up on the whole thing and fall back to replacing the secretary if
  there is a problem.  I'd rank that above FD, but I'd prefer the
  current proposal.

I'd appreciate any thoughts on this.

[toc] | [prev] | [next] | [standalone]

#3068

Sam Hartman <hartmans@debian.org> writes:

> In general I'm proposing that the chair of the TC make the decision of
> who acts as secretary for that vote.  The rationale there is that they
> are the backup secretary for a number of constitutional functions
> already.

This works for me.  Thank you!

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#3065

On Sun, 13 Feb 2022, Sam Hartman wrote:
> 1) Do not make the identity of a voter casting a particular vote
> public.

If we make all votes secret we should require that the voting system
used enables voters to validate that their vote was correctly recorded
and tabulated in the final vote count.

The existing system for DPL votes has this property, but future systems
might not.

We should also enable independent tabulation,[1] which you get
automatically when votes are not secret. [Devotee enables this currently
as well, but future non-devotee systems might not.]

I'd also appreciate hearing more specific examples of where someone
wasn't able to vote their true preference because the vote was public. I
currently plan to offer (or second) an amendment to this proposal which
strikes the section making all votes private and rank that higher than
one which struck it, but I'm open to be convinced otherwise.

My personal reasoning is that I see my role as a voting project member
as more of a stewardship role where I'm trying to decide what is best
for the project, rather than what is best for me personally, and I want
to be seen as being a good steward for the project. I also think the
large number of voters masks the impact of a single individual vote.
[But maybe this is a personal safety issue? Perhaps people should be
able to optionally mask their identity when voting? Not sure.]


1: Where someone can take each individual vote and calculate the results
themselves.

-- 
Don Armstrong                      https://www.donarmstrong.com

You could say to the Universe this is not /fair/. And the Universe
would say: Oh it isn't? Sorry.
 -- Terry Pratchett _Soul Music_ p357

[toc] | [prev] | [next] | [standalone]

#3066

[Multipart message — attachments visible in raw view] — view raw

>>>>> "Don" == Don Armstrong <don@debian.org> writes:
    Don> If we make all votes secret we should require that the voting
    Don> system used enables voters to validate that their vote was
    Don> correctly recorded and tabulated in the final vote count.
Note that our current constitution does not require this for DPL votes.
Do you think this is important enough to require in the constitution?
I'm guessing yes since you bring it up, but I want to ask explicitly.




    Don> We should also enable independent tabulation,[1] which you get
    Don> automatically when votes are not secret. [Devotee enables this
    Don> currently as well, but future non-devotee systems might not.]


    Don> 1: Where someone can take each individual vote and calculate
    Don> the results themselves.

Same question for this.

Would you be willing to propose a merge request for these two properties
if you think it is important that we require them in the constitution?

Do people like Pierre-Elliott who favor cryptographic approaches have
comments on these two properties?
I want to make sure that if we're ruling out some anonymous voting
system someone favors, we do so explicitly.

[toc] | [prev] | [next] | [standalone]

#3090

On Sun, 13 Feb 2022, Sam Hartman wrote:
> >>>>> "Don" == Don Armstrong <don@debian.org> writes:
>     Don> If we make all votes secret we should require that the voting
>     Don> system used enables voters to validate that their vote was
>     Don> correctly recorded and tabulated in the final vote count.
>
> Note that our current constitution does not require this for DPL votes.
> Do you think this is important enough to require in the constitution?
> I'm guessing yes since you bring it up, but I want to ask explicitly.

Yes. [If there wasn't discussion of replacing e-mail and devotee, I
wouldn't bother, since devotee already has this property.]

>     Don> We should also enable independent tabulation,[1] which you get
>     Don> automatically when votes are not secret. [Devotee enables this
>     Don> currently as well, but future non-devotee systems might not.]
>
> Would you be willing to propose a merge request for these two properties
> if you think it is important that we require them in the constitution?

I missed that §4.2.3 already requires this, though it probably needs to
be clarified. Let me work up a merge this.

-- 
Don Armstrong                      https://www.donarmstrong.com

Vimes hated and despised the privileges of rank, but they had this to
be said for them: At least they meant that you could hate and despise
them in comfort.
 -- Terry Pratchett _The Fifth Elephant_ p111

[toc] | [prev] | [next] | [standalone]

#3067

Hi,

On Sun, Feb 13, 2022 at 2:30 PM Don Armstrong <don@debian.org> wrote:
>
> I'd also appreciate hearing more specific examples of where someone
> wasn't able to vote their true preference because the vote was public.

People expecting (or maybe hoping for?) more political controversy may
feel differently; see below.

I personally would rather avoid the controversies, and the votes, that
lead to such fears.

> Recently posted here in another recent thread:
>
> This matter is extremely important for me, as soon as Debian starts
> voting political/social GRs and not only technical ones.

Kind regards
Felix Lechner

[toc] | [prev] | [next] | [standalone]

#3070

Felix Lechner <felix.lechner@lease-up.com> writes:

> People expecting (or maybe hoping for?) more political controversy may
> feel differently; see below.

> I personally would rather avoid the controversies, and the votes, that
> lead to such fears.

I'm not quite in agreement in that I think some controversies shouldn't be
avoided, but I largely feel similarly.  However, given that six members of
the project can force a vote on basically any topic, I don't think it's
realistic to assume that we will always be able to avoid political votes.
The bar to bringing a GR to a vote is (intentionally) not high.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#3082

[Multipart message — attachments visible in raw view] — view raw

>>>>> "Don" == Don Armstrong <don@debian.org> writes:
    Don> We should also enable independent tabulation,[1] which you get
    Don> automatically when votes are not secret. [Devotee enables this
    Don> currently as well, but future non-devotee systems might not.]

I think the following text already in the constitution is sufficient to
get you independent tabulation; am I missing something?
>Votes, tallies, and
>       results are not revealed during the voting period; after the vote
>       the Project Secretary lists all the votes cast. 

    Don> I'd also appreciate hearing more specific examples of where
    Don> someone wasn't able to vote their true preference because the
    Don> vote was public. I currently plan to offer (or second) an
    Don> amendment to this proposal which strikes the section making all
    Don> votes private and rank that higher than one which struck it,
    Don> but I'm open to be convinced otherwise.

    Don> My personal reasoning is that I see my role as a voting project
    Don> member as more of a stewardship role where I'm trying to decide
    Don> what is best for the project, rather than what is best for me
    Don> personally, and I want to be seen as being a good steward for
    Don> the project.

First, it looks like many participants in the discussion support your
view.  Right now, I haven't seen sufficient support for this proposal
that I would propose it as a GR.  If some of the people who advocated
for this during the rms GR don't step forward, I think we can avoid a
vote.

So, I think the key question is the one you raise above.
Are we acting as steward or are we acting on behalf of ourselves when we
vote in Debian?

In elections in my country, we have secret ballots.
One of the main reasons for that is that we don't want to be held to
account for our vote say either by our employers, or by a group of thugs
with baseball bats unhappy about how we voted.
That is, when we are making our own decisions as voters, we don't want
to have to explain our vote to anyone, and we don't want people to be
able to change their behavior toward us based on our vote.

In contrast, we typically demand that our elected representatives vote
publicly because we do want to hold them accountable: we want them to
account for ttheir votes to us when we decide whether to return them at
the next election.

If we are steward as Debian Developers, who are we stewards for?
Who should be able to hold us accountable?
I don't think we are representatives in the traditional sense of a
representative democracy.
Developers are not elected, and the same body that could potentially
remove us also has the franchise.
We have made a commitment that our goals are our users and the free
software community.
But I think the question is whether we will make better judgments  in
respecting those goals if we  need to be worried about how our votes
will be seen years later or how they will be used by people who disagree
with us.

Let's take the rms GR.

First, as a sponsor of one of the ballot options, I can definitely say I
got a lot more feedback both from within Debian and outside of Debian
than on any other thing I've sponsored.
Steve certainly found feedback he got to be harassment.
I did as well.

My understanding is that people on the other side of the issue got
feedback they believe was inappropriate as well.

My skin is fairly thick, but I absolutely can understand why people
aware of that harassment and contemplating voting would choose not to.
I think it is realistic to imagine that if Debian had made a statement
one way or another, someone who disagreed with that statement would have
done the leg work to make it easy for the Internet to express their
feelings at a set of voters.

Remember that the election was very close; one or two votes absolutely
would have changed the results.

But let's take some concrete examples.
I am not sure there were any FSF staff members who were DDs at the time
of the election.
(There have been FSF staff members who are developers in the past, but
there were a number of staffing changes at the FSF around then).
I think it entirely reasonable that a staff member might be worried
about how their employer would view a vote  critical of the president of
the organization.

Similarly, imagine a prominant developer at one of the organizations who
signed one of the letters and who was a DD.
It seems they might be uncomfortable voting against the position their
organization had taken.

I think these are both cases where our users and the free software
community would be better served by allowing people to vote what they
thought was best independent of pressure from outside employers or from
the Internet at large.
I think the concern about employers is significant enough that only
making votes available to other developers would be insufficient.

For me, I can't think of good reasons to actually know how someone else
voted.  I've been tempted to use that data over the years (and have
glanced at it from time to time), but a lot of the uses I would
considered were sketchy enough that I decided it would be inappropriate.
As an example, do I really want to decide whether I'm interested in
working with someone based on positions they took years ago?

Philip Hands did provide one good use of voter data: finding someone
who disagreed to talk to them about an issue.  I think that the list
of sponsors and those who took a public decision during discussions will
be sufficient that it will not be difficult to find someone  who can
explain an alternate position even if we hide who voted for what.

--Sam

[toc] | [prev] | [next] | [standalone]

#3086

Am Mon, Feb 14, 2022 at 08:53:23AM -0700 schrieb Sam Hartman:
> >>>>> "Don" == Don Armstrong <don@debian.org> writes:
>     Don> We should also enable independent tabulation,[1] which you get
>     Don> automatically when votes are not secret. [Devotee enables this
>     Don> currently as well, but future non-devotee systems might not.]
> 
> I think the following text already in the constitution is sufficient to
> get you independent tabulation; am I missing something?
> >Votes, tallies, and
> >       results are not revealed during the voting period; after the vote
> >       the Project Secretary lists all the votes cast. 
> 
>     Don> I'd also appreciate hearing more specific examples of where
>     Don> someone wasn't able to vote their true preference because the
>     Don> vote was public. I currently plan to offer (or second) an
>     Don> amendment to this proposal which strikes the section making all
>     Don> votes private and rank that higher than one which struck it,
>     Don> but I'm open to be convinced otherwise.
> 
>     Don> My personal reasoning is that I see my role as a voting project
>     Don> member as more of a stewardship role where I'm trying to decide
>     Don> what is best for the project, rather than what is best for me
>     Don> personally, and I want to be seen as being a good steward for
>     Don> the project.
> 
> First, it looks like many participants in the discussion support your
> view.  Right now, I haven't seen sufficient support for this proposal
> that I would propose it as a GR.  If some of the people who advocated
> for this during the rms GR don't step forward, I think we can avoid a
> vote.

I support a GR making votes in Debian secret by default (with
"secret" meaning "as in DPL votes").

> So, I think the key question is the one you raise above.
> Are we acting as steward or are we acting on behalf of ourselves when we
> vote in Debian?
> 
> In elections in my country, we have secret ballots.
> One of the main reasons for that is that we don't want to be held to
> account for our vote say either by our employers, or by a group of thugs
> with baseball bats unhappy about how we voted.
> That is, when we are making our own decisions as voters, we don't want
> to have to explain our vote to anyone, and we don't want people to be
> able to change their behavior toward us based on our vote.

+1

For a long time, effectively all GRs in Debian were about either
technical or purely Debian-internal organizational issues, where
(although I would have preferred secret votes there as well)
having a tally sheet that showed the individual votes usually
wasn't that much of a practical problem.

In my view, things have unfortunately changed for the worse in
recent times as I have the impression that certain groups within
Debian try to use the Debian project as a hammer to further their
personal political goals and don't care for the negative effects
they create for other developers with that.  The RMS GR can serve
as a practical example for that: it clearly wasn't about a
technical issue or some Debian-internal organizational issue, it
was about a highly explosive public political debate completely
external to Debian where there was IMHO absolutely no reason for
Debian as a project to become involved at all.  Every developer
is of course free to make a political statement on their own
behalf and can sign whatever petition they want in a personal
capacity.  Unfortunately the people in question weren't content
with stating their personal opinion on the matter but instead
tried to force all developers to make a public statement on their
behalf where it was completely clear from the beginning that
there wasn't even remotely something like a consenus on the whole
matter among the developers at large.

Forcing this GR on the developers left all developers with only
two choices: either to not vote at all and as a result have a
highly explosive political statement that they potentially don't
agree with (or even actively disagree with) published in their
name, or take part in the vote and be forced to have their
political views on the matter made public, political views which
they otherwise wouldn't have made public and whose publication
could easily have negative effects for them given the political
climate around the whole matter - a climate where people in both
"camps" had been sharpening their pitchforks and where having
one's personal views on the matter published (regardless of which
"side" one voted for) might well have negative consequences for
one's further professional career.

Making the vote secret doesn't solve the first problem
(potentially having a highly explosive political statement that
one doesn't agree with published in one's name), but it at least
solves the second problem (being forced to make one's political
views publicly known against one's will).

Regards,
Karsten
-- 
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.

[toc] | [prev] | [next] | [standalone]

#3089

[Multipart message — attachments visible in raw view] — view raw

On 2/14/22 09:53, Sam Hartman wrote:
> Steve certainly found feedback he got to be harassment.
> I did as well.

I received some harassment (not a lot, but some) over this too. My 
recollection is this was coming from non-DDs.

Given the levels of harassment that others were talking about at the 
time, I did put serious thought into to what extent I needed to loop my 
employer in on this. That was the first time I've ever had to consider 
such action for volunteer work, Debian, FOSS, or otherwise.


On Mon, Feb 14, 2022 at 5:56 AM Philip Hands <phil@hands.com> wrote:
> If we are assuming that some DDs might start attacking people based on
> the way they voted, then I'd suggest that it's more important to eject
> such toxic people from Debian than it is to try to mitigate their
> toxicity using measures that have negative side-effects.

I agree that we should expel toxic DDs. Nobody wants to work with jerks.

But secret ballots may be useful for other reasons, not least of which 
is that the harassment may come from outsiders, for which expulsion is 
not an available remedy. And even expulsion doesn't prevent a then 
former-DD from harassing people in the future, which we've seen happen; 
though of course this is not limited to voted positions.

Secret ballots are certainly not a panacea that solves all harassment, 
but they may be a risk reduction measure.


On 2/14/22 15:36 (later than the email below), Felix Lechner wrote:
[the above bit from Philip Hands quoted]
  > I see no way to expel people reliably based on what they might do.

I don't see anything in there suggesting we should expel people based on 
what they _might_ do.


On 2/14/22 12:42, Felix Lechner wrote:
[the above bit from Philip Hands quoted]
...
> All of them were condemned by later generations: the Salem witch hunt;
> McCartyism; the cultural revolution in China; collectivisation under
> Pol Pot in Cambodia; and perhaps most infamously the many attempts
> over time to expel or eradicate the Jews from various territories.

Expelling people (from a volunteer software project) who are acting in 
toxic ways is not remotely the same as any of those things, and even if 
you're against doing that, comparing it to the Holocaust is frankly 
disgusting.

This is a perfect example of behavior where the action is a problem 
regardless of the cause/intention. Either you are so lacking in 
experience, perspective, and/or judgement that you cannot see why this 
comment is inappropriate, or you know exactly what you are doing and are 
intentionally choosing to (act in bad faith to) wind people up.

If it's the former, then while your intentions may be good, you really 
need to understand that this is not okay, even if you don't/can't 
understand why. Stop posting such things. Moving forward, if you wish to 
participate in these discussions, maybe try having a friend privately 
review your email before posting publicly.

-- 
Richard

[toc] | [prev] | [next] | [standalone]

#3091

On Mon, 14 Feb 2022, Richard Laager wrote:
> On 2/14/22 09:53, Sam Hartman wrote:
> > Steve certainly found feedback he got to be harassment.
> > I did as well.
> 
> I received some harassment (not a lot, but some) over this too. My
> recollection is this was coming from non-DDs.

Without minimizing the totally unacceptable harassment that occurred,
all three of you seconded the proposals and were significantly more
visible than a voter listed on the tally page.

[...]

> Secret ballots are certainly not a panacea that solves all harassment,
> but they may be a risk reduction measure.

I see this as a possibility. I'm personally most concerned about someone
who isn't able/willing to vote because they feared harassment.

I'm likely biased because I'm in a privileged position and rarely have
to deal with concerted harassment directed specifically at me, so I
might be minimizing the real fear people have because I personally
haven't experienced it.

Perhaps the compromise position is to default to secret ballots, but
allow people to automatically unmask their preference at the appropriate
time. [Totally not supported by devotee currently, but certainly
possible to enable.]

-- 
Don Armstrong                      https://www.donarmstrong.com

The solution to a problem changes the problem.
 -- Peer's Law

[toc] | [prev] | [next] | [standalone]

#3092

Don Armstrong <don@debian.org> writes:

> I'm likely biased because I'm in a privileged position and rarely have
> to deal with concerted harassment directed specifically at me, so I
> might be minimizing the real fear people have because I personally
> haven't experienced it.

This is almost exactly my concern.

I'm not particularly worried about making all of my Debian votes public.
I've been on the Internet for a long time, have the resources to defend
myself against the sorts of reactions I think are likely, and am not the
sort of person who tends to draw the most attention anyway.  Maybe I'm too
optimistic since things seem to be getting worse, but I'm not very worried
for myself.

However, I think there's a bias implicit in that sort of analysis, and I
don't want only the Debian Developers who are similarly situated to be
able to vote.  If someone is more socially vulnerable than I am, I don't
want them to have to do this calculus in order to vote their conscience.

I agree with Sam's analysis that the point of Debian votes is to vote as
individuals, not to vote as trustees on behalf of a constituency, and
while I too have gotten valuable understanding and course correction from
seeing people I respect in the project vote differently than me, I don't
think public voting is a core project value.  I therefore find it hard to
argue against people's perceived safety (even if it is only a perception).

> Perhaps the compromise position is to default to secret ballots, but
> allow people to automatically unmask their preference at the appropriate
> time. [Totally not supported by devotee currently, but certainly
> possible to enable.]

That's an interesting thought.  My immediate reaction is that the social
signaling of who reveals their votes and who doesn't is a bit complicated
and I'm not sure what effect it would have.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#3094

[Multipart message — attachments visible in raw view] — view raw

Russ Allbery <rra@debian.org> writes:

> Don Armstrong <don@debian.org> writes:
>
>> I'm likely biased because I'm in a privileged position and rarely have
>> to deal with concerted harassment directed specifically at me, so I
>> might be minimizing the real fear people have because I personally
>> haven't experienced it.
>
> This is almost exactly my concern.
>
> I'm not particularly worried about making all of my Debian votes public.
> I've been on the Internet for a long time, have the resources to defend
> myself against the sorts of reactions I think are likely, and am not the
> sort of person who tends to draw the most attention anyway.  Maybe I'm too
> optimistic since things seem to be getting worse, but I'm not very worried
> for myself.
>
> However, I think there's a bias implicit in that sort of analysis, and I
> don't want only the Debian Developers who are similarly situated to be
> able to vote.  If someone is more socially vulnerable than I am, I don't
> want them to have to do this calculus in order to vote their conscience.

This sums up my position as well, but I suppose I was concerned that we
might stumble into doing something to protect the vulnerable based on
several privileged people's imaginings of what it might be like to be
vulnerable.

Of course, one cannot really expect someone who feels vulnerable to say
so in public.

I've had one person point out in private that they did feel vulnerable,
but in the end, steeled themselves to vote anyway -- I would hope that
we could arrive at a place where people don't have to go through that.

> I agree with Sam's analysis that the point of Debian votes is to vote as
> individuals, not to vote as trustees on behalf of a constituency, and
> while I too have gotten valuable understanding and course correction from
> seeing people I respect in the project vote differently than me, I don't
> think public voting is a core project value.  I therefore find it hard to
> argue against people's perceived safety (even if it is only a perception).

I find the idea that someone might be forced to reveal their previously
undeclared political views in order to vote particularly persuasive as a
reason to have as-secret-as-possible votes on at least those subjects.

Alternatively, we could just reach a consensus not to even attempt these
sorts of position statements in future, since all they do is highlight
divisions.

Given that we generally want DDs to be drawn from as diverse a
population as possible, we should expect our views on pretty-much any
subject other than Free Software to represent the full spectrum of
opinion, so drawing an arbitrary line somewhere and then getting the
project to divide on which side we should stand as a group is not likely
to give a useful result, but will give people reasons to be upset with
one another.

I don't really see that the secrecy of the ballot helps in such a case,
since most of the damage is done in the pre-vote discussion.

Perhaps we need a mechanism for people to express a view that a proposed
GR is something that we shouldn't be deciding, to quickly kill the
discussion if a (perhaps super) majority would rather just leave it
alone.

>> Perhaps the compromise position is to default to secret ballots, but
>> allow people to automatically unmask their preference at the appropriate
>> time. [Totally not supported by devotee currently, but certainly
>> possible to enable.]
>
> That's an interesting thought.  My immediate reaction is that the social
> signaling of who reveals their votes and who doesn't is a bit complicated
> and I'm not sure what effect it would have.

In a divisive argument, one grouping might well be able to expose their
opposition's votes by revealing their own.

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

[toc] | [prev] | [next] | [standalone]

#3097

Philip Hands <phil@hands.com> writes:

> I find the idea that someone might be forced to reveal their previously
> undeclared political views in order to vote particularly persuasive as a
> reason to have as-secret-as-possible votes on at least those subjects.

> Alternatively, we could just reach a consensus not to even attempt these
> sorts of position statements in future, since all they do is highlight
> divisions.

While I agree with this [*], I don't think it's sufficient because I don't
think position statements are the only sort of votes that can be
politicized, and the level of politicization in the world surrounding us
is growing stronger.  I find it hard to escape the conclusion that we're
going to have some vote in the future that will pose similar risks.
Examples of lines of discussion that I think the project cannot (and
should not) entirely avoid but that could lead to such a problem include
Debconf venue selection, anything related to the project code of conduct
including whether we should have one, and membership actions and their
potential overrides under 4.1.3.  I'll also point out that even technical
issues have become heavily polarized and have led to at least borderline
harrassment based on publicly stated positions (see systemd).

Trying to be generous to one another and only tackle divisions when they
are of central importance to the project is a good principle, but I think
there are some divisions of central importance to the project, not
everyone is going to agree on which divisions are of central importance,
and six DDs have a right under the constitution to bring a GR to a vote.
I'm also leery of getting into another situation where a vote is going to
be worrisome but we have no framework to mitigate the effects because
we've been overly hopeful that we could avoid any such vote.

[*] Full disclosure: I publicly supported one of the ballot options and
    voted several options above FD because I believed (possibly
    incorrectly) that once the Pandora's box of a GR was opened, it
    mattered what statement the project made, and, at that point, FD
    itself was a statement, but I would have preferred not to have opened
    the box in the first place.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#3098

Hi,

On Tue, Feb 15, 2022 at 12:31 PM Russ Allbery <rra@debian.org> wrote:
>
> Trying to be generous to one another and only tackle divisions when they
> are of central importance to the project is a good principle, but I think
> there are some divisions of central importance to the project, not
> everyone is going to agree on which divisions are of central importance,
> and six DDs have a right under the constitution to bring a GR to a vote.
> I'm also leery of getting into another situation where a vote is going to
> be worrisome but we have no framework to mitigate the effects because
> we've been overly hopeful that we could avoid any such vote.

Six DDs can force a vote, but not necessarily a decision. Would a
higher quorum help to ensure that divisive issues remain moot unless
there is broader interest?

A quorum of 48 voters may satisfy a statistician, but 125 might ensure
in addition that the issue being decided is in fact "of central
importance."

Kind regards
Felix Lechner

[toc] | [prev] | [next] | [standalone]

#3099

[Multipart message — attachments visible in raw view] — view raw

Felix Lechner <felix.lechner@lease-up.com> writes:

> Hi,
>
> On Tue, Feb 15, 2022 at 12:31 PM Russ Allbery <rra@debian.org> wrote:
>>
>> Trying to be generous to one another and only tackle divisions when they
>> are of central importance to the project is a good principle, but I think
>> there are some divisions of central importance to the project, not
>> everyone is going to agree on which divisions are of central importance,
>> and six DDs have a right under the constitution to bring a GR to a vote.
>> I'm also leery of getting into another situation where a vote is going to
>> be worrisome but we have no framework to mitigate the effects because
>> we've been overly hopeful that we could avoid any such vote.
>
> Six DDs can force a vote, but not necessarily a decision. Would a
> higher quorum help to ensure that divisive issues remain moot unless
> there is broader interest?

I was wondering if we could allow expressions of disdain
(anti-seconds?), such that a second would get cancelled out for every
two DDs (or maybe a larger multiple?) that respond to a call for seconds
with an anti-second. A proposal would then need to stay at above 6
seconds for some short period after the latest anti-second landed to be
considered to have a properly seconded proposal.

I'm not sure what one would want to do if a hundred anti-seconds landed
just too late.

That might of course be somewhat divisive too, since people may feel like
they didn't get a fair hearing, but would allow the project to express a
"Let's not go there" without having to discuss it for ages.

Also, if the declarations of disdain needed to be public, that would
disenfranchise anyone that's only going to vote in secret ballots. I
suppose one could do the anti-seconding in secret, but in that case one
would also need to allow at least some of the seconds to be secret as
well, to have an even playing field, which all seems a bit complicated.

Alternatively, we could just have this as an informal thing, where
people get to somehow declare their reaction to a GR discussion, in a
secret, rolling, self-selecting poll, with simple options like "please
make this stop" or "feel free to continue" ... and the numbers get
published.

The proposer of something that's obviously unpopular then gets to decide
if they're willing to continue pushing their idea anyway, regardless of
the fact that it's got no chance of success, and is only going to get
them a reputation for wasting everyone's time. They would of course also
have the chance at that point of persuading a silent majority (on who's
behalf they may think they speak) to express support in the poll, which
may make the opposition realise that there is a wider spectrum of
opinion than they thought, which may lead to better debate.

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

[toc] | [prev] | [next] | [standalone]

#3100

On Wed, Feb 16, 2022 at 09:11:58AM +0100, Philip Hands wrote:
> I was wondering if we could allow expressions of disdain
> (anti-seconds?), such that a second would get cancelled out for every
> two DDs (or maybe a larger multiple?) that respond to a call for seconds
> with an anti-second. A proposal would then need to stay at above 6
> seconds for some short period after the latest anti-second landed to be
> considered to have a properly seconded proposal.

That would be basically a vote to find out whether we want to vote on
something. I don't think that's a splendid idea.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

[toc] | [prev] | [next] | [standalone]

#3103

Philip Hands <phil@hands.com> writes:

> I was wondering if we could allow expressions of disdain
> (anti-seconds?), such that a second would get cancelled out for every
> two DDs (or maybe a larger multiple?) that respond to a call for seconds
> with an anti-second. A proposal would then need to stay at above 6
> seconds for some short period after the latest anti-second landed to be
> considered to have a properly seconded proposal.

This is a vote, though, just a kind of awkward one.  If we're going to
hold a vote, I think we should do it with decent software designed to
handle a vote, rather than asking some poor person to manually verify and
count mailing list messages.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#3104

[Multipart message — attachments visible in raw view] — view raw

Russ Allbery <rra@debian.org> writes:

> This is a vote, though, just a kind of awkward one.  If we're going to
> hold a vote, I think we should do it with decent software designed to
> handle a vote, rather than asking some poor person to manually verify and
> count mailing list messages.

I agree.

I'd personally be happier if Debian had very few GRs in the future, but
if we're going to vote about anything at all, I'd rather it be done via
a GR process that's "efficient" enough to get us to an answer without
completely disrupting everything...

Bdale

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | linux.debian.vote

csiph-web