Re: Security review of tag2upload

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> The attack that Simon is talking about doesn't require a
Russ> preimage attack, only a successful collision attack against
Russ> Git trees using SHAttered plus some assumptions about where
Russ> Git may be lazy about revalidating hashes.  It's an
Russ> interesting point that I didn't think of, although I'm not
Russ> sure that it would work against GitLab and thus against Salsa
Russ> and I think it's fairly trivial to protect against regardless.

Russ, I'm trying and failing to find time to  write a long response to
your security review.

But I'm going to try to make this point because I think it is relevant
and because it came up a number of times when I'm thinking about your
analysis.

You talk a number of times about whether an attack is possible against
salsa.  But especially when thinking about detection and tracing, I
think that things that are verified by signatures made with keys not
held by the system in question are harder to modify than things that can
be verified only so long as a system remains trusted.
One of the things that I found striking in the xz-utils attack was how
two different systems (the release tarballs) and git archives might have
been exploited to hide an attack.  If people looked at git and not the
archive, they might conclude there was no attack, even if they had been
alerted that there might be a problem.

Which is to say, especially in the moment when considering an incident,
people are very bad about reasoning about whether views of a system are
equivalent.

So, I consider the following to be useful to an attacker--to be threats
worth mitigating:

1) Attacker uploads malicious code to the archive.

2) Attacker possibly through a compromise of the dgit server and salsa
changes the git view to be something harmless.

Such an attack can be detected by regularly verifying  the archive
contents against git versions.
I do not have confidence that verification will hapen.
At least in my experience if I have a choice between git and unpacking a
dsc, I'll take git almost all the time.
I realize there are DDs who prefer the dsc.

Still, my initial read of your analysis is that you discount attacks
like this more than makes sense to me.
I also believe that hash collisions may make attacks like the above more
possible.

My strong suspicion  is that even if the classes of attack I am thinking
about are given the consideration I think they need, tag2upload will
still be reasonable from a security architecture standpoint.


signature.asc
Description: PGP signature

Re: Security review of tag2upload

[Sam Hartman]

I will write a more detailed response to Russ's analysis later.
I am behind on getting my packages into shape and I want to concentrate
on that for now.
I do agree with Russ's basic conclusion: we should decide whether to
adopt tag2upload for reasons other than security of the architecture.


Simon> For the "full possession of a key" scenario, the threat model
Simon> is that the attacker *would* have access to the victim's
Simon> private key, and therefore a rational attacker would validly
Simon> sign the upload with that, making it indistinguishable from a
Simon> legitimate upload by the victim
I think this is true for traditional uploads but not for tag2upload.

>> For me, that case and the "xz-utils" case are actually quite
>> pressing matters

Simon> The bottom line is that if the attacker has the victim's
Simon> private key material, then the attacker can do anything that
Simon> the victim can do, because in our key-based security model
Simon> the only way we can authenticate the victim remotely is that
Simon> they have control of their own private key(s),

We also have credentials that are used to log into salsa.
So, for tag2upload, we might find that we had additional mechanisms to
trace an attack because gitlab keeps track of which authenticated user
made a particular push.

I appreciate that in most cases the signatures are stronger, more
distributed credentials than gitlab's logs of who does a push.
But they are parallel mechanisms and a discrepancy between these can
help us detect and trace attacks.

Re: Question to all candidates: GDPR compliance review

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:
Adrian> If I send an email requesting all data Debian has about me to 
Adrian> data-protect...@debian.org, will I receive a complete reply within 
the 
Adrian> expected time, including all data members of delegations like the 
Adrian> Debian Account Managers and the Community Team might have?

Someone did exactly that while I was DPL.  They received a response
within the GPR's allowed time giving them all data Debian held regarding
them that was not covered by an exception to the GDPR.  They also
received a list of exceptions to the GDPR that might apply to data that
was not turned over.  This was all handled in a manner consistent with
the advice received from a lawyer specializing in GDPR issues that was
ultimately paid for by SPI.

As you might imagine, there are GDPR exceptions that apply to some
classes of data that DAM routinely processes.
I cannot speak to the community team as the community team did not exist
at the time of this request.

--Sam

Re: Question to all candidates: Bits from the DPL?

[Sam Hartman]

> "Andreas" == Andreas Tille  writes:
Andreas> I was told in private that a daily log in Git might be a bit tough 
but
Andreas> I hope to manage.  I consider it a good preparation for the 
monthly Bits.

I think I recall inheriting some infrastructure from Chris for
maintaining some DPL news that was accessible to DDs or to future DPLs
or something, but not in git and not public.
Ah, yeah, master.debian.org:/srv/leader/news
I used it sometimes, but definitely not daily.
I think Chris used it more effectively.

I don't remember how I tracked what to cover in my bits emails.
I think I did look at the news files, and I also just had a few issues I
knew I was going to cover.
I also looked back at lea...@debian.org mail to see if there were things
happening that I should boost.

--Sam


signature.asc
Description: PGP signature

Re: Question to candidates: what are your quantitative diversity goals and metrics?

[Sam Hartman]

> "Roberto" == Roberto C Sánchez  writes:
Roberto> I can infer that you likely view the current ratio of around 3% 
women
Roberto> (33/1004) and around 96% men ((1004-33)/1004) [0] (and, yes, I 
recognize
Roberto> that this does not account for gender minority individuals, but I 
was
Roberto> not able to locate figures for that group). However, what is not 
clear
Roberto> is at what point, in your own view, the situation is imbalanced. 
Would
Roberto> you consider 65% men, 25% women, and 10% gender minority to have an
Roberto> overrepresentation of men?

Why does it matter?
It seems implausible that  we would get from 3% women to a point where
we had a good gender balance in a year?

So why does the particular threshold matter at all?

Re: Candidates question: politics and Debian

[Sam Hartman]

> "Thomas" == Thomas Koch  writes:

Thomas> A question to DPL candidates

Generally we mwait until the campaining period for questions to the
candidates.
I mean it's a list, you can post to it  whenever, but those conventions
do help us.

Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"

[Sam Hartman]

> "Bart" == Bart Martens  writes:
>> 
>> * A commercial company writes free-software that for all
>> practical purposes can be used only for access to their
>> proprietary web service.  I'd rather not allow arguments about
>> whether a flaw is on the web service side or the client API side
>> to be used to help the company get out of liability to their
>> customers/users.

Bart> I guess "awscli" is an example of this situation.

Sure, let's say it is.
One could quibble about whether there are alternate implementations of
AWS's API, but for most uses, I'd agree with awscli being an example of
what I'm talking about.

Bart> https://packages.debian.org/sid/awscli
Bart> 
https://metadata.ftp-master.debian.org/changelogs//main/a/awscli/awscli_2.12.0-1_copyright
Bart> So the EU would hold Amazon liable for damages caused by using
Bart> "awscli", overruling the "without warranties" clause in the
Bart> license. Well, then next time Amazon might choose to only
Bart> provide documentation of the API, without publishing an open
Bart> source example implementation like "awscli". That's a loss for
Bart> foss. It illustrates the value of DFSG 6.

Ah, because the regulations specifically exclude SAAS and so Amazon
doesn't have liability for the API unless they publish software to use
the API?

If that's your point, I certainly understand you better.

If in practice we end up with less open-source software because of
things like that, I agree it would be a negative.

Now that I think I understand you better, I'm going to step aside and
let the Europeans debate this.
Thanks for helping me understand your point.

Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"

[Sam Hartman]

> "Bart" == Bart Martens  writes:

Bart> On Wed, Nov 15, 2023 at 02:52:31PM +0100, Lucas Nussbaum wrote:
>> I wonder if we should have something like "Free software
>> development by nonprofit organizations" somewhere.

Bart> Are we now drawing a line between profit and nonprofit? In my
Bart> view, with Free Software it should not matter who produces,
Bart> publishes or uses the software, in commercial or nonprofit
Bart> context. That is, in my view, an essential element of the
Bart> continuous growth and success of Free Software. This should be
Bart> the main message if Debian would make a public statement in
Bart> this context. Debian should not try to fix the EU text by
Bart> defining which categories of contributors are to be
Bart> protected. On the contrary, we should aim at keeping the
Bart> existing freedoms for anyone alike, including commercial
Bart> companies. That is also publishing open source software under
Bart> licenses with the usual disclaimers of liabilities.

I think that when your practices can be best described as monatizing
your customers, or monatizing the users of your open-source software,
then you have extended beyond the free-software ethos, and I think
commercial liability makes sense.

So let's consider some situations.

* A commercial company writes free software.  Should they have liability
  to someone who grabs that software uses it unrelated to that company's
  business and they never make money from that person?  Example: A large
  company makes a useful library that they and others use; the library
  is ancillary to their business; they do not provide support for the
  library.
  I'd generally say that the commercial company is writing free software
  and I agree that Debian should support the idea they should have all
  the protections of anyone writing free software.

* A commercial company writes free-software that for all practical
  purposes can be used only for access to their proprietary web
  service.  I'd rather not allow arguments about whether a flaw is on
  the web service side or the client API side to be used to help the
  company get out of liability to their customers/users.

*A company writes software.  They sell support for that software.  They
 have a track record of being bad about providing security updates to
 people who do not pay for support; it is hinted that this helps them
 drive support revenue.
I think they should be in the same boat as any company giving software
 away for free and also selling support.  I.E. the fact that the source
 is available should not in this instance help them escape liability.
 Whether not giving away security updates for free should be considered
 good business or a social evil seems like a debate for another forum,
 but I don't think open source should be a factor here.

So, there are some cases where I agree with you that the commercial
nature of the company should not matter to free software protection and
other cases where it is a lot less clear to me.

I do think we want to avoid cases where releasing something as free
software or open source increases liability over giving the same
software away for gratis as closed-source.

--Sam

Re: On community and conflicts

[Sam Hartman]

> "Roberto" == Roberto C Sánchez  writes:
Roberto> I'm afraid that you miss the point.  I specifically chose
Roberto> flat earth, & co., as a contrast.  My position is that we
Roberto> are all adults, capable of deciding for ourselves and that,
Roberto> absent some behavior that is a clear violation of the Code
Roberto> of Conduct and/or mailing list rules (e.g., harassment),
Roberto> simply uttering something that some people do not like does
Roberto> not form cause for removing someone, or even for issuing
Roberto> any sort of warning.  Else, why bother having a Code of
Roberto> Conduct and mailing list rules?

   
So, I think that this boils down to one of the big disagreements that is
challenging at least the part of the world where I live in.

You can put it several ways.
Are killfiles effective?
Is ignoring people sufficient?

Are communities harmed by long discussions   even when everyone can
ignore the discussion.

Or if you view things a bit differently...  Are communities harmed by
bullshit?  Does not taking steps to limit classes of ideas (even when
people can ignore them)  create the perception those ideas are tolerated
in the community?  Does such tolerance make classes of people feel
unwelcome?
Does lack of tolerance of those ideas make classes of people unwelcome?

We're all adults and we can just ignore that is an idea that some of us
have come  to reject.  For people like me, Russ, Steve, and a few
others, I think coming to that conclusion took years.  I certainly know
that I started out somewhere close to where you are today.
For other members of our community who lacked certain privileges in the
context of Debian and the Internet, I suspect coming to the conclusion
that killfiles and ignoring was insufficient took a lot less time.

For myself, it's quite clear  that people are not actually *just adults
that ignore it*.
There are lots of reasons for that.  Some of them I regret--like how in
a community where we all have a voice we tend to debate everything,
rather than asking ourselves whether we need to participate.  Which is
to say that there is a human tendency against just ignoring it even when
we can.
Other ideas I find I do not regret like the idea that I will not stand
for people being hurt in the community because of who they are.
(And yes, I understand there are members of the community who believe
hurt should only be used in relation to physical actions--I find myself
not in agreement with that.)


I was not involved in actions taken in response to Thomas's messages.  I
cannot remember if I was a DAM trainee during any part of that, but my
recollection is that I was never involved in any significant way.
I was definitely not involved in DAM when he was expelled from the
project; I even sent mail questioning a small part of DAM's message.

But I can respond in the general context and comment on how I think
about just ignoring Thomas's ideas if I disagreed with them.
It's quite clear to me that many people were going to respond to
Thomas's conspiracy theories.  They did.
They did not just ignore it.
It was disruptive, and disruptive of Debian's mission.
This was true even before DAM acted.
Even before any action was taken, people were not ignoring Thomas's
messages.

Thomas's messages were disrupting our mailing lists in a way that is in
my mind inconsistent with our mailing list rules.
Creating a huge stir of off-topic messages--creating a flame war as we
used to call it--is and ought to be inconsistent with the mailing list
rules.

DAM sent Thomas a warning, and in discussions with Thomas he *agreed not
to do it again*.

Trust is important.
If in a proceeding with DAM you make some promise about your future
behavior, and then later violate that promise, that's a big deal.
In my mind, going back on your word in a situation like that very much
is an actionably big deal.
And DAM acted.

It might have been different if Thomas wrote to DAM and said that after
consideration, he thought DAM was wrong and he would not be able to
abide by his promise.  Thomas and DAM could have figured out how to
approach that--Thomas could for example have tried to get support for a
GR if he felt DAM was being unreasonable in expecting such a promise.
But if you say you're not going to do something, and you then go do it
without withdrawing your commitment, you have broken trust.

Trust is really important in our community.  DDs have a lot of power.  I
support DAM in acting when people break trust with them or with the
community.
--Sam

Re: General Resolution: Liquidate donated assets as soon as possible

[Sam Hartman]

> "Milan" == Milan Kupcevic  writes:

Milan> Pollo,

Milan> I trust your best intention but I hold that these decisions
Milan> should be worked out by the Project Leader and/or appointed
Milan> delegates in coordination with TOs and with help of qualified
Milan> advisers. They might decide to have a general rule but they
Milan> could also weigh in on case by case basis. We should not tie
Milan> their hands by passing a GR.

Strong agree.

I don't think we need a GR in this space, but if we end up with enough
seconds that we're going to have a vote, I'd support such a ballot
option.

Re: Question to all candidates: GDPR compliance review

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:
Adrian> Your "services" approach does not work for the non-trivial
Adrian> cases where Debian might be a (joint) controller of personal
Adrian> data.

Adrian> The Debian Community Team promises confidentiality regarding
Adrian> personal information they receive about other people,[1]
Adrian> which conflicts with the legal obligation of informing the
Adrian> person about whom personal information is being processed or
Adrian> stored.

Based on legal advice I received while acting as DPL, the above is not
correct.
Most of the information the community team process is not information we
would need to disclose in response to a GDPR subject access request.

Debian has already dealt with at least one subject access request  that
dealt significantly with information held by DAM in its role as a
delegated team.
Some of that information was responsive; some of that information was
covered by exceptions.
The data protection team was looped into the process we and our lawyer
used in responding to the request.
The data protection team (and my successor as DPL) received copies of
the legal advice we received.


--Sam

Re: Results for Voting secrecy

[Sam Hartman]

> "Kurt" == Kurt Roeckx  writes:


>> It inadvertently weakened the constitutional protection against
>> changes to the constitution.

Kurt> I currently fail to see how it does.

I think Felix's point is that if we had choice 1, 2 and Nota,

People who preferred option 3 would vote N>2=1 or some such.

Because choice 3 was on the ballot, people had options that reflected
their preferences and so some of those people voted 3>2>N.

I.E. voters tend to  shy away from ranking options below NOTA.

In super-majority races, we effectively ask voters two questions:

1) Do you think the option is acceptable--that is, do you  rank it above
NOTA.

2) Which option do you prefer.

Felix's point is that the voters who preferred option 3 actually had the
power to make it win, provided they were willing to say that they found
option 2 unacceptable.
Felix's assumption is that if they realized they had that power, they
would have exercised it.

That's doubtless true for some voters: our voting system is complicated.

However, I've generally found that Debian members are fairly good about
distinguishing what they consider acceptable and what they consider
their prference.
My suspicion is that a good chunk of voters did vote correctly according
to their desires.

My suspicion is that many of the people who would prefer to reaffirm our
old voting system also found  the change acceptable.

Re: Question to all candidates: registering Debian as an organization

[Sam Hartman]

> "Richard" == Richard Laager  writes:

Richard> On 3/20/22 07:10, Felix Lechner wrote:
>> If we accidentally formed a General Partnership, as has been
>> suggested elsewhere

Richard> Yes, that would be really dumb for a number of reasons.

The problem is that at least in the US, you can accidentally default to
a general partnership.
Effectively, if you are doing things together, and it cannot be shown
what you have instead, and mumble mumble I'm not a lawyer, a court may
conclude you are a general partnership.

So, it's more what steps have you taken to avoid being considered a
general partnership?
Unfortunately I cannot point to a lot of these steps for Debian.

Re: To all candidates: Debian and people with disabilities

[Sam Hartman]

> "Jonathan" == Jonathan Carter  writes:
Jonathan> I installed a Jitsi server for Debian (it's a system for
Jonathan> making group video calls), and was really proud that we
Jonathan> had this... until we had some blind people join some calls
Jonathan> and learned how utterly inaccessible it is.  For example,
Jonathan> you can toggle your mic or camera (there's no way to set
Jonathan> it as either on or off explicitly) and then you have to be
Jonathan> able to see the mic or camera icon on your screen in order
Jonathan> to tell whether those are enabled or not.

This has gotten much much better.

* You can hold down space bar in orca focus mode, when you release, you
  know you will be muted.
  (push to talk key)

* The accessibility of the icons is much better.
The buttons are "pressed" when muted and this displays through to orca.

There are still a few things that are not perfect, but Jitsi
accessibility is on par with Zoom and Teams from my standpoint these
days.

Re: Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification

[Sam Hartman]

>>>>> "Kurt" == Kurt Roeckx  writes:

Kurt> On Mon, Mar 07, 2022 at 03:12:57PM -0700, Sam Hartman wrote:
>> >>>>> "Judit" == Judit Foglszinger  writes:
>> 
>> >> I think it would be clearer to add "that" between "confirm"
>> and >> "their":
>> >> 
>> >> {+ public, but developers will be given an option to confirm
>> that >> their vote is included in the votes+} cast.
>> 
Judit> I agree.  It makes this option diverge a bit from the Option
Judit> A it was forked from, but since the meaning is not changed it
Judit> should be fine.
>> 
>> Should I adopt the change as well or does it only make sense for
>> ballot option 2?

Kurt> Sam,

Kurt> Can you confirm that you would also like this change?

I decline; it's too late to do without a chance of getting something
wrong.

I should have prepared a new commit a couple days ago and confirmed
there are no objections.
The way my option is worded, I'd need to generate a new commit hash,
confirm that it didn't include any extra changes etc.
It's too late to do that and I think the text is correct either way.
In US English, "that" is optional in that sentence.
I don't know what UK rules would say.


signature.asc
Description: PGP signature

Re: Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification

[Sam Hartman]

> "Judit" == Judit Foglszinger  writes:

>> I think it would be clearer to add "that" between "confirm" and
>> "their":
>> 
>> {+ public, but developers will be given an option to confirm that
>> their vote is included in the votes+} cast.

Judit> I agree.  It makes this option diverge a bit from the Option
Judit> A it was forked from, but since the meaning is not changed it
Judit> should be fine.

Should I adopt the change as well or does it only make sense for ballot
option 2?

I haven't been following closely.

Lynx is not Accessibility

[Sam Hartman]

> "Thorsten" == Thorsten Glaser  writes:

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

Thorsten> This is a very bad idea.

Hi.
Several of the issues you brig up are legitimate trade offs, and while
we probably 
see them differently, let's let the voters decide rather than get into a
large debate.

I have to take exception with one point you bring up.


Thorsten> Alternative solutions may • have accessibility problems
Thorsten> (not work with lynx, for example

Working with Lynx is not a requirement for accessibility.
Obviously accessibility depends on what your requirements are.
The needs of someone who is blind are different than than for someone
who has mobility issues for example.

I stopped using Lynx many many years ago.  Originally it was because
some sites just weren't usable in Lynx and I wanted to use them.
At that point there were already other browsers that were available to
users running a screen reader that worked with these sites.
Free software accessibility was  limited to Lynx for a while, although
edbrowse  did have its moment as the best thing available.
Ah, Amazon on edbrowse!:-)

These days though,  modern browsers actually have better
technology for navigating a web page accessibly than Lynx does.

I regularly use and develop using both Chromium and Firefox.

There are people who want to continue using Lynx.  Some of them even
because they want to use a console screen reader.  That's fine, but it
is not directly an accessibility issue.  In some cases it is because
people have financial constraints that may also be related to their
disability, and as a result they want to get the most out of the
computer they have.  And yes, that's accessibility related, but it is
misleading to simply say doesn't work with Lynx == accessibility
problem.

Please, especially if you don't use accessible interfaces on a
regular basis please don't spread the myth that Lynx == accessibility.

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

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

[Sam Hartman]

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


4.2. Procedure
@@ -228,9 +246,10 @@ 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 in sufficient
detail that anyone may verify 

Re: Draft Amendment for Rationale Section

[Sam Hartman]

> "Sean" == Sean Whitton  writes:
Sean> Could we have a diff, please?


--- /tmp/old2022-03-02 16:48:23.358673871 -0700
+++ /tmp/new2022-03-02 16:48:00.945961500 -0700
@@ -1,7 +1,7 @@
 Rationale
 =
 
-During the vote for GR_2021_002o, several developers said they were
+ 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
@@ -13,13 +13,20 @@
 
 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
+ 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.
 
-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.
+ [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.

Draft Amendment for Rationale Section

[Sam Hartman]

I'd like to update the rationale section of my GR to fix a typo and to
better explain the differences between this option and other ballot
options.  If sponsors of my option do not have comments I intend to
formally amend my option tomorrow.  Sponsors would then have an
additional 24-hours to object.

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.


signature.asc
Description: PGP signature

Re: Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> I completely agree with separating *unrelated* changes, but
Russ> the whole point of this discussion is that some folks believe
Russ> the changes are closely related, to the extent that one of the
Russ> changes may not be desirable unless the other one is made at
Russ> the same time.

Russ and I have studied the same Debian history herey, so it is
unsurprising we have come to the same conclusion on this.
The above is a good summary of my position.

As I explained to Martin, I'd be very open to an amendment to my ballot
option to better explain why these changes might be related.
I tried to do that in the existing rationale.


signature.asc
Description: PGP signature

Re: Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]

[Sam Hartman]

> "Don" == Don Armstrong  writes:

>> However, I don't think it should take a 3:1 super majority to
>> change how we collect votes.

Don> I don't want it to take a 3:1 majority to add additional
Don> methods (web based, I'm presuming), but I think not allowing a
Don> signed (and/or encrypted) emailed ballot to count should
Don> require a 3:1 majority. [

Okay, then I recommend that you work on a ballot option.
I agree with Pierre-Elliott that the constitution is not where we should
specify the details of how to vote.


signature.asc
Description: PGP signature

Re: Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]

[Sam Hartman]

> "Don" == Don Armstrong  writes:

Don> Rationale: e-mail should continue to be an option for casting
Don> votes even while alternative methods of casting ballots might
Don> also be allowed.

I'm supportive of a change here, and let's see if we can work out
something that we both like.
IN particular, I agree with the following:

1) As long as it make sense, we should continue to support email voting.

2) It needs sufficient project support to drop email voting.  That
shouldn't be something the secretary does all on their own.
I'm sure Kurt wouldn't, but I also understand the desire to write these
things down.

However, I don't think it should take a 3:1 super majority to change how
we collect votes.
Whether I can vote by email just isn't as important as the DFSG, , our
commitment to our users and free software, or the
separation between DPL and DAM to me, or the idea that I can never be
forced to do Debian work.

I suspect that it would take a GR to change how we conduct votes, but I'd
prefer not even to require that.
If someone leads a discussion that reaches a rough consensus that some
other voting system is good enough, I don't see why we'd need to have a
GR at that point.

I think there are two reasons why we might want to adjust our voting.
First, there's the anonymous voting systems people have been talking
about.
I personally don't care about that, but I also don't want to add stop
energy to the work of others.

The second is that a number of developers do have trouble voting.
In past elections where some parties wanted to strongly encourage voting
we've seenn people write software to help developers fill out ballots.
Now, I admit that in the instance I'm thinking of, a significant chunk
of the motivation appeared to be political.
But I've certainly helped other Debian developers cast their ballots.
Even for people who do regular packaging work, getting GPG working in a
mainly Windows or gmail mail flow is a pain and is not easy.
And sure, while going through NM, obviously these people did have some
solution to generate GPG signed mail regularly.
But it's not clear that participating in one election is enough of a
motivation to get  that all working again.

And yes, I agree with you that  a lot of the ways I personally would
work on fixing that problem would still make it easy to accept email
ballots.
In Debian we've generally embodied the principle that those doing the
work get significant latitude in how the work gets done.
To me, mandating email voting in the constitution is us telling the
secretary how to do their job, potentially  ruling out options that make
their work harder and are demotivating.
It also means that we need more bureaucracy for change.

So, I'm wondering whether it would be enough to make it clear that
changing the voting system beyond doing what we do for DPL discussions
requires adequate project consensus.

I'm thinking something along the lines of:

1) Update the rationale

2) In the General resolution system, in addition to the constitutional
amendment, include a statement of the day asking the secretary to obtain
sufficient project consensus before changing how voting works.

I'd be happy to draft text for those two items if that would address
your concern without creating a 3:1 super majority to change how we
conduct voting.
--Sam


signature.asc
Description: PGP signature

Re: Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification

[Sam Hartman]

> "Martin" == Martin Michlmayr  writes:


Yes, I think 3) and 4) are much more important in hidden votes.

Even without 2, the constitution gives the secretary significant
flexibility in how the voting system is set up.
With hidden votes, several of us believe it is more likely that people
could end up disagreeing with how the secretary decided to set things
up.

That's especially true if people in the project are considering pushing
for some sort of anonymous voting scheme.
It seems very likely we would want to debate those details,
and leaving that to one person without recourse if we disagree is
problematic.

I think change 2 (not requiring email) makes the anonymous voting
efforts easier but is not a strict requirement.

So, if I were going to unbundle this, I'd first want to see changes 3)
and 4) approved before I'd be comfortable voting for 1, 2 and 6.

I'd definitely be interested in improvements to the rationale of my
ballot option to better explain why changes 3-4 are something you
probably want to approve before 1, 2 and 6.

I absolutely agree that these changes would be split into multiple
commits in a software project
I think they would be one merge request though, and if I were the one
approving the merging, I'd want 3-4 in the first merge request if it
were split into two merge requests.


signature.asc
Description: PGP signature

Re: Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification

[Sam Hartman]

> "Judit" == Judit Foglszinger  writes:


Judit> Give the opportunity to vote for secret voting without
Judit> needing to additionally vote for unrelated/only slightly
Judit> related constitution changes; for example for the change of
Judit> mode of voting from email to something not defined.

Even if you don't want to move toward some different voting system, do
we really want to require a constitutional amendment if say the
secretary wanted to move voting to a salsa-authenticated website to make
it easier and more accessible to our members?
Back when the constitution was passed, email was so obvious for this
sort of thing that it wasn't a real limitation.

Today, I think there are all sorts of reasons we might  prefer a
different way to interact with the voting system, and  I don't want to
need to change the constitution every time we want to make such a
change.

--Sam

Re: GR: Hide Identities of Developers Casting a Particular Vote

[Sam Hartman]

> "Pierre-Elliott" == Pierre-Elliott Bécue  writes:

Pierre-Elliott> I sponsor the resolution quoted below.

I haven't gone and checked signatures, but unless someone's signature is
bad or something, I think that gives us more than enough sponsors.

--Sam

Re: GR: Hide Identities of Developers Casting a Particular Vote

[Sam Hartman]

I wanted to give a diff from what I published as the second round to
what I formally proposed.
The changes should be removal of the text about putting secretary
decisions on hold and  some indentation fixes in the rationale.

@@ -40,22 +40,20 @@ Summary of Changes
outcome requires a 3:1 majority.  The chair of the technical committee
decides who conducts such votes.

[-5) Clarify that decisions of the secretary or their delegates can be put-]
[-on hold.-]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 
[-dfc2e6b1cd4ac13c3ee11e1f7f3ff3a1450af52d.-]{+ed88a1e3c1fc367ee89620a73047d84a797c9a1d.+}
As of February [-13,-]{+23,+} 2022, this commit can be found at
[-https://salsa.debian.org/hartmans/webwml/-/commit/dfc2e6b1cd4ac13c3ee11e1f7f3ff3a1450af52d-]{+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.
  

@@ -86,18 +84,6 @@ In the normal case ( 7.2) where+} the project


4.2. Procedure
[-@@ -198,9 +216,9 @@ earlier can overrule everyone listed later.-]
[-Delaying a decision by the Project Leader or their Delegate:-]

[--]
[-  If the Project Leader or their Delegate, {+the project secretary 
or-]
[-their delegate,+} or the Technical-]
[-  Committee, has made a decision, then Developers can override them-]
[-  by passing a resolution to do so; see-]
[-[-4.1(3).-]{+4.1(3), 4.1(4), and 4.1(8).+}-]

[-  If such a resolution is sponsored by at least 2K Developers,-]
[-  or if it is proposed by the Technical Committee, the resolution-]
@@ -228,9 +246,10 @@ earlier can overrule everyone listed later.

   Votes are taken by the Project Secretary. Votes, tallies, and
@@ -127,6 +113,3 @@ varied by up
  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 options on the ballot will be those candidates who have-]
[-  nominated themselves and have not yet withdrawn, plus None Of The-]


signature.asc
Description: PGP signature

GR: Hide Identities of Developers Casting a Particular Vote

[Sam Hartman]

I propose the followiwng general resolution, which will require a 3:1
super majority to pass.
I'm seeking sponsors for this resolution.

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.


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


4.2. Procedure
@@ -228,9 +246,10 @@ 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 in sufficient 
detail that anyone may verify the outcome of the election from the votes cast. 
The+}
{+   identity of a developer casting a particular vote is not made+}
{+   public, but developers will be given an option to confirm their vote 
is included in the votes+} cast. The voting period is 2 weeks, but may be 
varied by up
   to 1 week by the Project Leader. 

  

@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.
  

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

  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 

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

[Sam Hartman]

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

> "Russ" == Russ Allbery  writes:

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

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

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

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

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



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

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


Russ> To me, the critical points are that:

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

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


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

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

>> Even with things like calling for the vote, I suspect that in
>> practice a secretary would delay the vote while there was a
>> discussion in full swing about some secretary decisions, text in
>> the constitution not withstanding.

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

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


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

If other people would like to see the option allowing secretary
decisions to be placed on hold removed, I will remove it.
The specific class of decisions that are related to the rest of the
proposal are unlikely to need to be placed on hold.

Russ> Maybe "mechanism" rather than "option"?  Option implies to me
Russ> that it might be some sort of up-front choice the voter has to
Russ> make.

But it is an up-front choice today.
If you have an encryption subkey, you get to participate.
If you don't then you do not.
I used the word option specifically to capture that right now it is an
up-front choice.

Russ> Here's the sort of situation that I'm worried about:

Russ> * Some GR is proposed and is discussed for a couple of weeks.
Russ> * Near the end of the discussion period, the Project Secretary
Russ> says that this vote requires a 3:1 majority.  * Some
Russ> developers disagree and propose a GR to override that
Russ> decision.  * That GR gets 2K sponsors.

Russ> Now, under this new text, the Project Secretary's decision is
Russ> "put on hold."  However, the constitution requires that the
Russ> Project Secretary start a vote on the GR because its
Russ> discussion period has ended.  So what does putting that
Russ> decision on hold *mean*?

I guess the secretary would need to interpret the constitution.  If I
were secretary, I'd say that the discussion is done, but that we cannot
hold the vote until the issue surrounding the super-majority is
resolved.
Another fine option would be to conduct the vote but to determine the
outcome later after the super majority is resolved.

I guess that since we've identified this particular conflict we could
resolve it  explicitly one way or another.

I don't think no matter how hard we try we will be able to resolve all
the conflicts in the constitution, so I am more interested in making
sure there are mechanisms to interpret and build up experience over
time than to try and make sure things are unambiguous.




Unfortunately, even more than  other decisions, project secretary
decisions are very often timely.

I agree that  the specific class of decisions--decisions about how votes
are conducted--that contemplated the proposal of 4.1(8) are not timely
in this manner.
And so I'd be okay removing my change to make secretary decisions able
to be put on hold if that would gain broader support.

Unfortunately, I think that just moves the problem around.
Let's say there's no language talking about putting a decision on hold.
What do we do if someone overrides the decision about what super
majority is required ?
We're still left with a mess.

And if we decide to remove the language about being able to override the
secrety entirely, in one of the situations where people really care, we
just end up in extra-constitutional territory fairly quickly.

IN other words, I think we are exposing and acknowledging mesiness that
was already inherent in the system.  Even with things like calling for
the vote, I suspect that in practice a secretary would delay the vote
while there was a discussion in full swing about some secretary
decisions, text in the constitution not withstanding.


signature.asc
Description: PGP signature

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

[Sam Hartman]

Here's a diff to the  rationale section:

Rationale
=

@@ -21,7 +20,7 @@ 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.

@@ -41,22 +40,28 @@ Summary of Changes
outcome requires a 3:1 majority.  The chair of the technical committee
decides who conducts such votes.

{+5) Clarify that decisions of the secretary or their delegates can be put+}
{+on hold.+}

{+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 
[-030405434d040e14bbebebaeda64555b5c1ee16a.-]{+dfc2e6b1cd4ac13c3ee11e1f7f3ff3a1450af52d.+}
As of February 13, 2022, this commit can be found at
[-https://salsa.debian.org/hartmans/webwml/-/commit/030405434d040e14bbebebaeda64555b5c1ee16a-]{+https://salsa.debian.org/hartmans/webwml/-/commit/dfc2e6b1cd4ac13c3ee11e1f7f3ff3a1450af52d+}

For convenience a word-diff of the changes is included below.  In case
the diff differs from the commit, the commit governs.



And here's  the set of patches in rev 2 on top of rev 1
@@ -216,9 +216,9 @@ earlier can overrule everyone listed later.
Delaying a decision by the Project Leader or their Delegate:


  If the Project Leader or their Delegate, {+the project secretary or 
their delegate,+} or the Technical
  Committee, has made a decision, then Developers can override them
  by passing a resolution to do so; see 
[-4.1(3).-]{+4.1(3), 4.1(4), and 4.1(8).+}

  If such a resolution is sponsored by at least 2K Developers,
  or if it is proposed by the Technical Committee, the resolution
@@ -246,9 +246,9 @@ 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 in sufficient 
detail that anyone may verify the outcome of the election from the votes+} 
cast. The
   identity of a developer casting a particular vote is not made
   [-public.-]{+public, but developers will be given an option to confirm 
their vote is included in the votes cast.+} The voting period is 2 weeks, but 
may be varied by up
   to 1 week by the Project Leader. 

  


signature.asc
Description: PGP signature

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

[Sam Hartman]

Hi.
Here's an updated proposal  based on discussion so far.
The changes were the ones I said I'd make Thursday:

1) include secretary decisions in the list of decisions that can be put
on hold.

2) Attempt to address Don's concerns regarding independent verification
of the tally and verification by individual developers that their votes
are counted.

The language around allowing individual developers to verify their votes
is a bit awkward.
Today as I understand it, you don't receive a vote hash if your GPG key
doesn't support encryption.
I didn't want to encode this in the constitution one way or another, so
I phrased things the way I did.

I'll send a diff of changes in the next message.


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.

5) Clarify that decisions of the secretary or their delegates can be put
on hold.

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 dfc2e6b1cd4ac13c3ee11e1f7f3ff3a1450af52d.
As of February 13, 2022, this commit can be found at
https://salsa.debian.org/hartmans/webwml/-/commit/dfc2e6b1cd4ac13c3ee11e1f7f3ff3a1450af52d

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


4.2. Procedure
@@ -198,9 +216,9 @@ earlier can overrule everyone listed later.
Delaying a decision by the Project Leader or their Delegate:


  If the Project Leader or their Delegate, {+the project secretary or 
their delegate,+} or the Technical
  Committee, has made a decision, then Developers can override them
  by passing a resolution to do so; see 
[-4.1(3).-]{+4.1(3), 4.1(4), and 4.1(8).+}

  If such a resolution is sponsored by at least 2K Developers,
  or if it is proposed 

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

[Sam Hartman]

I hear where people are coming from, when they talk about not wanting to
bundle things, but do not plan to conduct multiple
votes.
Fortunately, especially under the constitutional amendment we just
passed, others who want us to act differently have the flexibility to
argue for that.

One of the things I've learned being in Debian for over 20 years is that
agreeing on the question is sometimes harder than agreeing on the
answer.
Whether something is "bundled" or not depends on how you view the
problem.  I think the best example of this was the init systems
discussion within the TC, although it was clear that during several GRs
we never did come to agreement on what question we were voting on.


IN this instance, I consider the secretary changes sufficiently related
to the secret vote changes that I don't consider them bundled.  Also,
given the DPL's concerns about the number of GRs that are queued, I'd
rather not have more votes than we need.  I also believe that what I'm
is consistent with what we've done in the past.
Russ's proposal, which we just passed, included changes both to the TC
voting process and to the GR voting process.
We chose to vote on them all at once because they were related.
In my mind the changes are related enough that  it might affect how I
rank them.


It's also a reasonable position to view the secretary changes
as seperable and even to argue about whether the secretary changes or
the secret ballot changes should happen first.  It's even reasonable to
argue about whether removing the requirement that votes be conducted via
email is a third separable option.  And you could even disagree on the
order of all three of these potentially independent votes.



If you would like to see things unbundled, you have a few options:
Once there is a formal GR on the table, you could:

1) propose and unbundled option.
For example, if you think we should vote on the secretary changes first
and you like them, you could propose an option that includes the
secretary changes without the secret ballot changes.
That option would also be appealing to people who like the secretary
changes but who never want to see the secret ballot changes pass.  You
might think that's great.  Or you might want to explicitly add text to
your option saying that you think  we should vote on secret ballots
later, so that if your option wins, people don't think we'vedecided
against secret ballots.


2) If you don't want to see things intermingled on the same ballot, you
could propose an option explaining what order you think we should vote
on.
Something like "The Debian project believes these issues should be
decided in separate votes.  We should first decide on whether to have a
mechanism for overriding the secretary and then decide on  whether to
have secret ballots."

Voters will then get to choose whether they want to get it all over with
at
wonce or whether they want to handle things separately.
I think that's the best way we can do given that we have historically
found it next to impossible to agree on what question we are asking or
what order to ask them in.

--Sam

Re: Secret Ballots: How Secret

[Sam Hartman]

> "Bill" == Bill Allombert  writes:


You are absolutely right.
And in fact Don proposes to embody a requirement in the constitution
that would prevent plausible deniability in favor of allowing voters to
confirm their votes were counted.

And yet, we've been living with this trade off for DPL elections for the
entire lifetime of the project.

So, that's absolutely a weakness.


Would you prefer that we not mandate that voters be able to verify their
votes were counted so that we could have plausibel deniability?

Are there aspects of DPL elections that make this less of an issue for
DPL elections than other issues?

--Sam

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

[Sam Hartman]

> "Bill" == Bill Blough  writes:


Okay, this message spoke to me powerfully.
I'm now in the strongly supporting this proposal camp, rather than the
hey I think this is a good idea and I'll do the leg work because it's a
way I can help out promote a good idea.
For me, even one person saying that they couldn't vote as they wished is
strong enough to overcome the benefits of public voting I am aware of.

I know a number of people have been interested in some mechanism to
make votes sometimes public.
I'd encourage you to work together and be prepared with an amendment
(which will probably be its own ballot option) to do that.

I think we're still waiting on text to resolve Don's desire that voters
be able to verify ttheir vote.
(As a reminder they can today, but Don proposes making that a
requirement and no one has disagreed.)
If Don doesn't get to that I'll  propose text.

I also notice that I didn't update section 4.1 to indicate that
secretary decisions can be put on hold; that's currently limited to TC
decisions and DPL (delegate) decisions.
I'll make that change too.

So expect a revised version in a few days.

I expect a timeline like:

1) Revised version in 2-3 days

2) say 3-4 days of comment on that

3) Formally propose and ask for sponsors.  Once sponsors come in, that
starts the real clock.

--Sam


signature.asc
Description: PGP signature

Re: FYI, Secret Ballots Proposal is Likely to Die for Lack of Support

[Sam Hartman]

> "Richard" == Richard Laager  writes:

Richard> Your secret ballots proposal had some other procedural
Richard> housekeeping bits in it, like dealing with overrides for
Richard> the secretary. How do you feel about the consensus on that?

I think we're fairly close to a proposal there that the people who care
about are happy with.
I'd want Kurt to chime in.

Personally, I don't know if those are important enough to vote on unless
they are attached to something else.
If people want me to propose that I'm okay doing so.

--Sam

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

[Sam Hartman]

> "Don" == Don Armstrong  writes:

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

My suspicion is that if Debian had made a statement in either direction,
this would have expanded well beyond people who seconded the proposals.
I also recall people who became aware of the harassment people who
seconded faced and concluded they were uncomfortable voting.
Which in and of itself is a problem.

But yes, I do understand the point you've been making.


I think there are problematic uses of votes well beyond harassment
though.

* After this, I think the next vote is going to be about firmware.
Do we want companies like Nvidia who may have opinions about how
distributions should think about freedom looking at how people vote when
they consider hiring DDs?

* Do we want ftpmaster members looking back at past votes on firmware
  and DFSG interpretations before deciding someone is an appropriate
  candidate?

* Would it be reasonable for the DPL to look back at votes to decide
  whether to delegate to someone?

* I personally think some of the options on the systemd ballot were
  really bad ideas.  Not just that I disagreed with them, but I think
  that going down that route would have been amazingly bad for teh
  project.
  Is it reasonable for me to  go around holding it against people who
  ranked those options above FD?

I think that if we continue to have public ballots we accept that all
these sorts of things will happen, even if we wish they wouldn't.
The more I think about it, the more I think it would be reasonable to be
concerned about this sort of history building up and to be reluctant to
vote in some cases.
I think for a number of reasons it would be better if we discourage all
the use of voting data I hypothesize above.
I think the best way to do that is not to make the data public and not
to retain it for a long period of time at all.

Personally, I don't think that restricting voting data to DDs solves
many of the issues above.  We could attach a strong policy for how the
data would be used, but by the time we got done figuring out such a
policy, I think we'd just be better off not making the data available in
the first place.

--Sam

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

[Sam Hartman]

> "Don" == Don Armstrong  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

Re: Secret Ballots: How Secret

[Sam Hartman]

> "Russ" == Russ Allbery  writes:
Russ> [*] I do want to acknowledge, however, that having the
Russ> *capability* for verification even if almost no one uses it
Russ> routinely does provide real protection against shenanigans,
Russ> since it means should anyone suspect shenanigans a bunch of
Russ> people can go back and verify their votes even if they didn't
Russ> initially, provided they retained the necessary information.

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

That's why I'm comfortable with the DPL approach.
I doubt people do verifications regularly, but I bet there would be a
lot more verifications happening if the results were surprising or
especially if someone claimed their verification had failed.

--Sam

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

[Sam Hartman]

> "Don" == Don Armstrong  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.



signature.asc
Description: PGP signature

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

[Sam Hartman]

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.


signature.asc
Description: PGP signature

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

[Sam Hartman]

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. 

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


4.2. Procedure
@@ -228,9 +246,10 @@ 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
   {+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. 

  

@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.
  

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

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

Re: Secret Ballots: How Secret

[Sam Hartman]

> "Holger" == Holger Levsen  writes:

>> He asked that in a thread discussing stuff related to the project
>> secretary, and I didn't think an answer belonged there.

Holger> However that thread has 'secret ballots' in it's subject, so
Holger> I still find it very relevant to the topic discussed there,

Clearly, we would not organize the discussion the same way.
It sounds like you heard me to say that I thought your message was
off-topic in that thread.
I'd ask you to hear me differently.
I thought my answer would have been off-topic, and as the one answering,
I got to choose where to put it.

I focused on my needs and desires in the message I wrote today, and I
regret that you read commentary about judgment of your actions that was
not present in what I wrote.
Yes, I would have been happier if you had gone back and replied to the
earlier secret ballot thread rather than bringing up this issue in the
thread I started specific to the question about the secretary.
But I didn't think you did anything wrong.  I thought you viewed things
differently than I id.
And as the one answering, I tried to find a solution that we'd both be
comfortable with.

--Sam

Secret Ballots: How Secret

[Sam Hartman]

TL;DR: I'm proposing that  the way we handle DPL elections today is a
good start for what secret means.



Holger asked what I meant by secret.
He asked that in a thread discussing stuff related to the project
secretary, and I didn't think an answer belonged there.
So I'm starting a separate thread.

As a reminder, this all comes out of  GR 2021_002, where we had a fairly
controversial statement with many ballot options.
Several people raised the concern that they felt uncomfortable voting if
their ballot choices were going to be up on the Internet for everyone to
see.

People were much more concerned about that than worried that the
secretary might disclose their vote.

I think the way we handle DPL elections  is a good compromise between
secrecy and accountability.  (At least assuming that we do not retain
the actual votes long term.)


* The ballots are public, but the mapping from voters to ballot is not.

* Voters get a hash sufficient to prove that their ballot is included in
  the totals.

* The list of voters is public.

Anyone can verify that the ballots correspond to the totals.
Anyone can verify that their ballot was included in the totals.

An attacker can mount a number of attacks on this system

- They can include an extra vote.  They need to add someone who would be
  a valid voter.  They run the risk that person notices they were
  included even though they did not vote.

- They can change a vote.  They run the risk that voter will attempt to
  verify their vote and discover it is counted incorrectly.

Assuming the secretary is well trusted, I think those attacks are
acceptable residual risk from a security standpoint.

If it were up to me, that's where I'd leave things.  I might double
check that we had a data retention policy and that the way we present
hashes to people a voter can verify the hash includes their voter
identity.
But for my level of paranoia, I think the way we handle DPL elections is
fairly good.

Pierre-Elliott, who is another one of the drivers for the secret ballot
work was interested in exploring other options, involving better
cryptographic proof.
The plan was to go put together a DEP on anonymous secret voting.

I don't want to wait for that DEP, and I don't know how the discussions
will conclude.

I also don't think those details belong in the constitution.

So, effectively, the proposal:

1) Removes the claim that what people vote for becomes public after the
election

2) Leaves the specific voting mechanism up to the secretary (removing
the strict requirement it happen via email)

3) Provides a way for the project to override the secretary if theiy
disagree with the voting mechanism

I proposed specific text for points 1-2 above back  when this thread
started.
I proposed text for point 3 a couple weeks ago.

My plan is to go refine the specific proposals based on comments on the
list and publish things in the form of a diff to the constitution later
today.

If this proposal passes, Pierre-Elliott and others interested in more
advanced secret voting schemes can work on that.  If they convince the
secretary, we can use those proposals.  Kurt in particular has always
saught input from the project, and I think would be good at judging
consensus in a situation like that.  I'd imagine any secretary who
replaces Kurt would seek consensus on a big policy like that.  And if
somehow the project disagrees, we'd have recourse.


signature.asc
Description: PGP signature

Re: Secret Ballots: Handling Disagreement with the Secretary

[Sam Hartman]

I plan to release a complete proposal for secret ballots including the
proposed 4.1.8 within the next couple of days.

Is
https://salsa.debian.org/rra/webwml/-/commit/3f0f679ae97095915eea4b7299f16d74874c80da
my best starting point for a diff?


>>>>> "Don" == Don Armstrong  writes:

Don> On Fri, 04 Feb 2022, Sam Hartman wrote:
>> I see two ways of reading section 4.1.7:
>> 
>> 1) If the DPL and secretary disagree on any issue then the
>> project can replace the secretary.
>> 
>> 2) If the DPL and secretary disagree on the only issue where the
>> two of them both get to have an opinion (namely who is the next
>> secretary), the project decides.
>> 
>> So it's not clear to me that section 4.1.7 allows the secretary
>> to be replaced out of cycle. If we had a big conflict with the
>> secretary, I'd obviously argue for interpretation 1, but that
>> aspect of the constitution is not so clear to me.

Don> I think the plainest reading is #1, but I can see the argument
Don> that #2 was the intention.

Unless I hear objections I will propose text clarifying this to be
unambiguously #1.

>> I don't understand what you mean here. Are you worried that the
>> project might replace the secretary with a 1:1 majority to get
>> around a determination that some ballot option required a 3:1
>> majority?

Don> Yes. I think the additional complexity of requiring a 3:1
Don> majority to overrule the secretary isn't enough to always have
Don> the desired effect if §4.1.7 isn't also modified accordingly.

Don> That said, if a majority uses the blunt force of §4.1.7 to try
Don> to get its way by removing people, I'd be more concerned about
Don> the health of the project than whether we had written rules to
Don> prevent it.

For this reason, I don't currently plan to propose to modify 4.1.7.
The project is fairly good about interpreting the reasons behind
proposals.
I actually think in practice it would be harder to remove a secretary
for doing their job and making a controversial call about what super
majority was required than it would be to get a 3:1 majority behind
anything.

On the other hand, I can see cases where the project would try to take
advantage of an override that was lower than the super majority.
I'm not even imagining situations where people are  trying to abuse the
process--just a case where they disagree with the secretary, and where
if we don't have language in the constitution, the override vote could
be easier than winning the super majority itself.

That said, I'd certainly be happy to revise things if we get a consensus
here.
I think most of what we're discussing would be things I'd rank well
above NOTA.

Re: Waiting for the voting vote to finish... :-)

[Sam Hartman]

> "Steve" == Steve McIntyre  writes:

Steve> Hey Sam, I hope you're well!
Steve> Any progress on that please?

Yeah, I started a thread back on January 29 to focus on the big open
issue we discovered before deciding to defer things in the first round.
I think as of last Friday, we have an understanding of that issue.  I
will summarize shortly.  Within a couple days, I will post a new round
of the proposal with handling disagreement with the secretary folded in.
At that point the thing that would move things along the fastest would
be to review the proposal and comment.


--Sam

Re: Secret Ballots: Handling Disagreement with the Secretary

[Sam Hartman]

Replying to two messages:

Russ> The question this raises for me is who runs the vote to decide whether to
Russ>  override the Project Secretary?  I would completely trust Kurt to run 
that
Russ>  vote, but in the general case the Project Secretary running a vote on
Russ>  whether to override the Project Secretary is a clear conflict of 
interest.

Russ>  We could require that such a vote be done by public ballot regardless of
Russ>  any secret ballot mechanism for other votes, which gives us some built-in
Russ>  defense against any problems, but it still makes me a little bit leery to
Russ>  set up a situation where someone is running a vote about overriding a
Russ>  decision that they may feel strongly about.

I think delegation is the simplest solution here.
At various points the secretary has had a helper.  I recall a situation
where (Niel I think) temporarily removed his access to secretary stuff,
I think because he was running for DPL.

Constitution 7.1 permits the secretary to delegate power.
Constitution 7.2 says that if the secretary is unavailable the chair of
the TC acts as secretary (or delegates that decision).

I think we have a couple choices here:
We could decide that for such overrides the decision is always delegated
and that the TC chair either runs the vote or delegates.
That's probably simplest.

I agree that the secretary should step out of the way if the decision is
controversial.  In some cases it might be a matter of policy--for
example debating which specific technical mechanism to use for secret
ballots.  In a situation like that I wouldn't typically mind the
secretary running the vote.  Although I guess in such a situation the
project could give the secretary advice rather than overriding a
decision.


My current thinking is that if we are overriding the secretary, the TC
chair should act as secretary or delegate who conducts the vote.
(I would not explicitly rule out the TC chair delegating back to
secretary).

In researching this message, I realized that I need to correct my
proposal to allow decisions of secretary delegates to be overridden as
well.
I do not propose to have a fallback if the TC chair's decision
acting as secretary needs  to have a fallback.
I think the TC chair should delegate that, but I think that will be an
unusual enough path that I don't want to figure out who it gets
delegated to by default.
I would trust the TC chair with the advice of the secretary and DPL to
find someone to run that vote.


>>>>> "don" == Don Armstrong  writes:

Don> On Sat, 29 Jan 2022, Sam Hartman wrote:
>> So, to be specific, I propose to add a paragraph 8 to section 4.1
>> (powers of the developers):
>> 
>> 8. Override a decision of the secretary. Overriding the
>> secretary's determination of the majority required for a ballot
>> option or overriding the determination of the outcome of a vote
>> requires that the developers agree by a 3:1 majority. The
>> secretary's determination of whether a 3:1 majority is required
>> to override the project secretary is not itself subject to
>> override.

Don> I see the intention here. My initial thought is that the
Don> constitution already enables overriding by replacing the
Don> secretary through §4.1.7, assuming the project leader and
Don> secretary disagree.


I see two ways of reading section 4.1.7:

1) If the DPL and secretary disagree on any issue then the project can
replace the secretary.

2) If the DPL and secretary disagree on the only issue where the two of
them both get to have an opinion (namely who is the next secretary), the
project decides.

So it's not clear to me that section 4.1.7 allows the secretary to be
replaced out of cycle.
If we had a big conflict with the secretary, I'd obviously argue for
interpretation 1, but that aspect of the constitution is not so clear to
me.
Don> If we add this, the intersection of §4.1.8 and §4.1.7 should be
Don> addressed when it comes to questions requiring a supermajority.

I don't understand what you mean here.
Are you worried that the project might replace the secretary with a 1:1
majority to get around a determination that some ballot option required
a 3:1 majority?


signature.asc
Description: PGP signature

Re: Secret Ballots: Handling Disagreement with the Secretary

[Sam Hartman]

> "Jean-Philippe" == Jean-Philippe MENGUAL  writes:
Jean-Philippe> secret vote does not make part of them, if I remember
Jean-Philippe> correctly the constitution and the debate, so the
Jean-Philippe> debate was about intrepreting the text about this.

The specific question that rose to this discussion is how should we give
developers an ability to object if the manner in which the secretary
wants to conduct a vote is objectionable.  For example say a secretary
wanted to use a Google form rather than an email vote.

In my proposal all ballots would be secret, and the secretary would not
make a determination about that.

--Sam

Secret Ballots: Handling Disagreement with the Secretary

[Sam Hartman]

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


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

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

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

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

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

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


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

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

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

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


signature.asc
Description: PGP signature

Re: General Resolution: Change the resolution process: First call for votes

[Sam Hartman]

> "Andreas" == Andreas Beckmann  writes:
Andreas> What is "Russ' proposal"?  My first thought was: Why is
Andreas> this making a reference to something from the previous
Andreas> discussion period without explicitly stating it?

You are correct that Russ's proposal is Choice 1.

Re: GR: Change the resolution process (2021-11-25 revision)

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Apologies for not having followed up on this message yet.  I
Russ> got rather busy with non-Debian things for a bit.

Russ> To provide a status update, I think Kurt identified several
Russ> significant issues and we need another revision.  I hope to
Russ> finish that soon, at least by next weekend if not sooner.

Russ> There are several things that I think are fairly
Russ> straightforward to fix.  The open questions that I was hoping
Russ> to get some further feedback on were:

Russ> * Should we say that the proposers of ballot options need to
Russ> provide the short summaries at the end of the discussion
Russ> period, or should we specify that the Project Secretary writes
Russ> them?

We could leave that up to the project secretary.
I.E. allow the secretary to establish policies and procedures and refine
them over time.
Something like
"The project secretary may require summaries of ballot proposals and may
revise provided summaries."

I'd imagine that this is one of those things where different project
secretaries may view things differently depending on how comfortable
they are summarizing.

I think all too often we specify more than we need to in the
constitution.

Russ> * Is everyone okay with changing five days to seven days in
Russ> the rule on when the Project Secretary needs to start a vote
Russ> after the end of the discussion period?

I do not object.

Russ> * Should we use a different term than "call for a vote" to
Russ> describe the Project Secretary starting the vote?

No, I'd prefer to keep call for a vote.


signature.asc
Description: PGP signature

Re: GR: Change the resolution process (corrected)

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:

Wouter> Hi Kurt,
Wouter> On Thu, Dec 02, 2021 at 06:45:24PM +0100, Kurt Roeckx wrote:
Wouter> It was always my intent that the discussion time can be kept
Wouter> alive as long as it has not yet expired, but that it cannot
Wouter> be revived once it has expired. But I now think it does not
Wouter> forbid someone from sponsoring an extension proposal when
Wouter> the discussion time has already expired.

Wouter> So I think I should add the following to my A.3:

Wouter> 6. Once the discussion time expires, any pending time
Wouter> extension proposals that have not yet received their
Wouter> required number of sponsors are null and void, and no
Wouter> further time extensions may be proposed.

Wouter> Or is that superfluous?

Please say one way or the other so we don't fight about it later:-)
Thanks for noticing this.

So, out of morbid curiosity about the current formal process.  If you
propose this change, can Russ accept it for you, or could he only do
that if he accepts your entire proposal as an amendment?


signature.asc
Description: PGP signature

Re: GR: Change the resolution process (2021-11-25 revision)

[Sam Hartman]

> "Russ" == Russ Allbery  writes:
>>> 7. Proposing a general resolution.
>>> 
>>> When the Technical Committee proposes a general resolution or a
>>> ballot option in a general resolution to the project under point
>>> 4.2.1, it may delegate the authority to withdraw, amend, or make
>>> minor changes to the ballot option to one of its members. If it
>>> does not do so, these decisions must be made by resolution of
>>> the Technical Committee.

>> How do they delegate that? Using a resolution?

Russ> That was what I was assuming because I don't think the TC has
Russ> any other decision-making mechanism than that, but I guess
Russ> that's not completely clear in the constitution.  Maybe add
Russ> "(via a resolution)" after "delegate"?

I would object to this.  In particular I'd object to adding a
constitutional bar to the TC using some other decision making mechanism
were it to exist, or to making it easier to create such a mechanism.
I'd be happy to support adding text making it clear that delegation by
resolution is sufficient.  I just don't want to close out other
mechanisms


The only other such mechanism that  may exist today would be the TC
passing by resolution some operating procedures.
For example the TC might pass a general policy by resolution that unless
otherwise specified this power was delegated to the TC chair.
I don't want to handle the question of whether the TC can do that now,
and I certainly don't want to rule it out,
I'd object to exclusive language.

If someone feels the need I'd support something lik like adding "such as
by resolution".


signature.asc
Description: PGP signature

Re: Possible fourth ballot option

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Wouter Verhelst  writes:
>> On Mon, Nov 29, 2021 at 08:55:19PM +0100, Lucas Nussbaum wrote:

>>> Instead of the quite complex procedure proposed by Wouter,
>>> couldn't we patch the DPL's power to increase or decrease the
>>> the discussion period to allow the DPL to extend it beyond three
>>> weeks?

>> The downside of doing that is that if the DPL does this, then it
>> is a fairly political action, with all downsides of that method:
>> if there is a group of developers who would like the time to be
>> extended and a group who doesn't, then the DPL will be caught
>> between a rock and a hard place, and will be yelled at by one
>> group or the other, regardless of which decision they take.

Russ> Yes, this exactly.  When drafting my original proposal, I
Russ> thought about this possibility, but I think it puts the DPL in
Russ> an incredibly difficult position where they will be accused of
Russ> political bias no matter what they do.

Strongly agreed.  I was trying very carefully to use this DPL power
during the systemd resolution to make the options I proposed work like
options others proposed.  Even that accumulated a fair bit of
frustration.
Giving this power to the DPL makes the DPL job more challenging,
especially if the DPL is actually trying to lead and proposing ballot
options that are in the middle.

Re: GR: Change the resolution process (2021-11-25 revision)

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Here is an updated version of my proposal, which incorporates
Russ> the formal amendment to change the default option for TC
Russ> resolutions to also be "None of the above" and fixes two
Russ> typos.

I still support this and my second still stands.
I also agree this message is unnecessary as I understand the procedures.


signature.asc
Description: PGP signature

Re: Waiting for the voting vote to finish... :-)

[Sam Hartman]

> "Steve" == Steve McIntyre  writes:

Steve> Hey folks, I've got something else to talk about
Steve> (firmware!!), but I'll wait until this current discussion and
Steve> vote is finished before I start. Let's not overload people.

would you be willing to let peb and I propose the secret ballots GR?
We were hoping we were in line behind Russ.

--Sam

Re: GR: Change the resolution process (corrected)

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> I propose the following General Resolution, which will require
Russ> a 3:1 majority, and am seeking sponsors.


I second your proposed GR regarding voting systems improvements and do
not object to the minor change Philip pointed out and you accepted.


signature.asc
Description: PGP signature

Re: Draft GR for resolution process changes

[Sam Hartman]

> "Charles" == Charles Plessy  writes:
Charles> One last question: in some complex GRs there were
Charles> discussions about problems caused by mixing 1:1 and 3:1
Charles> majority options, which frankly speaking I could not
Charles> undertand because I never studied our Condorcet method in
Charles> details.  Do you think that such mixes can be problemating
Charles>

I can explain the issues I see.
Whether they are problematic depends on how you think things ought to
work.

1) Debian prefers an answer to FD.
So, consider the following options:

1) Change the DFSG.
2)  The DFSG is great
3) FD

Option 1 defeats option 2
Option 1 defeats option 3 by say 2.0:1

So, option 1 cannot win because option 1 needs to defeat option 3 by
3:1 to win.

There are two reasonable things we could have said the rules cause to
happen in that case.  First, we could have said that if an option would
have won but for super majority, then inherently FD wins.
Or we could (and did) say that option gets dropped.
So in the situation above, "The DFSG is great" wins even though more
people would have preferred to replace the DFSG than to say it was
great.

I've intentionally phrased things to maximize how bad it sounds.

If we allowed FD to win in this situation, it would be open to strategic
abuse: you could potentially drag out the discussion by  introducing a
supermajority option that you thought would win, but not win enough.

But it also seems like the current system is open to abuse because  of
the situation I described above.
Whether that's true depends on how you think about FD.

Consider another restatement of the results above.

Most people are either okay revising the DFSG or saying the DFSG is
great.
Both options are fine with the project.
More people would prefer to revise the DFSG, but not enough people to
actually permit the change.
We prefer to be done with discussions rather than have them drag out,
and we've encoded that to a certain extent in our constitution.
So, we decided to say the DFSG was great because we could do that today
rather than let things drag out.


2) There's another issue  involving supermajorities.

In a ballot like the one we're about to face, I might have an incentive
to rank an opposing constitutional amendment below FD even though I'd
rather see that amendment succeed than have more discussion.  After all
it might fail its super majority if enough people do that.
Again, whether this is abuse depends a lot on how you think about voter
intent.

The only way to avoid all of these issues is to avoid super majorities
entirely.

We're effectively saying that there are cases where the voters prefer
some option, and we're not going to let the voters choose that option
because they don't prefer it enough.
I think that is going to open up some strategic abuse somewhere.
The question is what sort of abuse do you permit.

Russ's proposal does not make any changes in these areas.
I actually think we have a good set of trade offs already and so I'm
happy with that.
But others might like a different set of trade offs.


signature.asc
Description: PGP signature

Re: Draft GR for resolution process changes

[Sam Hartman]

> "Timo" == Timo Röhling  writes:
Timo> I must say I find your reasoning convincing. A certain
Timo> stability of ballot options is desirable, and as our voting
Timo> scheme does not suffer from spoiler effects, we can afford to
Timo> keep the odd stale option. Besides, as you pointed out, the
Timo> original proposer can always formally withdraw and ask their
Timo> sponsors to do the same; if there is hidden support, it will
Timo> either materialize or the option will be discarded; no
Timo> additional procedural rules required.

I too find the reasoning convincing.


signature.asc
Description: PGP signature

Re: Do we want to Handle Secret Ballots in the same GR as Voting Changes

[Sam Hartman]

>>>>> "Carsten" == Carsten Leonhardt  writes:

Carsten> FTR, I'd also prefer a separate GR.

Since no one prefers combining these efforts, let's come back to secret
ballots after Russ's resolution is resolved.

Carsten> Sam Hartman  writes:
>> new: 6. Votes are cast in a manner suitable to the Secretary. The
>> Secretary determines for each poll whether voters can change
>> their votes.

Carsten> The manner needs to also be suitable to the voters.

Thanks for bringing this issue forward.

Looking over the constitution, it looks like the
developers as a whole have no recourse if they disagree with a decision
of the secretary.
We can  bikeshed on what rules lawyering we could apply to effectively
get to a new secretary in the shortest time in that case.
(Yes, I do see paths for doing that).
Instead, let's not and consider the idea that we should provide some
mechanism for the developers to disagree with the secretary over
something like this.
And yes, I think it's fine for that to be part of the secret ballot
work.





signature.asc
Description: PGP signature

Re: Do we want to Handle Secret Ballots in the same GR as Voting Changes

[Sam Hartman]

Holger> all of this and additionally personally I'd also find it
Holger> disrespectful to hijack/piggyback (on) Russ' work.


I'm frustrated reading this message because it sounds like you've jumped
to the assumption that I'm  hijacking Russ's work without coordinating
with him.
I don't think you've asked either Russ or me that.
As it turns out, Russ, Pierre-Elliott and I have been discussing voting
changes for months, and we've been splitting the energy of who  works on
what.
Pierre-Elliott was originally working on secret ballots, but got busy
and was in favor of me bringing the question forward.

I hope that in similar future situations, you ask rather than jumping to
disrespect.

--Sam

Re: Draft GR for resolution process changes

[Sam Hartman]

>>>>> "Russ" == Russ Allbery  writes:

Russ> Sam Hartman  writes:
Charles> - About the sponsors, if there are too many, then the
Charles> proposer is more at risk to face vetos when accepting
Charles> amendments.  (I write that as I accepted major changes as
Charles> the proposer of a GR option some years ago.)  Would it make
Charles> sense to limit the total number of sponsors, and to only
Charles> allow developers to sponsor one option ?

>> I don't understand this concern very well.  If some of your
>> sponsors don't like an amendment you accepted you can withdraw.
>> So long as you have k sponsors remaining, the option can stay on
>> the ballot.

>> What am I missing that leads to your concern?

It sounds like what russ and Charles are talking about is the following:

* You as a proposer want to accept an amendment

* A sponsor objects, and so you can't even though you would have been
  able to if you had fewer sponsors.

I have an alternate proposed fix:

If the proposer accepts the amendment and there are k sponsors who have
not objected, the amendment is accepted.
(I think it's okay even if we end up counting new sponsors to get to k
who have not objected)


Obviously sponsors who don't like the amendment can go off and propose
their own ballot options.

My rationale is that we'd rather not have things be dependent on
strategic ordering of who gets accepted as a sponsor etc.


In the current constitution, the proposer of the resolution is all sorts
of special, and has special powers and so we want to carefully control
what amendments they can accept.

But under Russ's approach, the whole amendment process is really just a
convenience to make it easier to update an option with less withdrawing
and  re-proposing.
I think we want to let proposers change their text provided they have
enough support at the end of the day, so let's effectively say that.

I am sympathetic to the desire to avoid having seconds/sponsorships pile
on.
And yet, I'd prefer not to have a hard limit.
I know I've found myself in cases where it was quite important to me to
be seen as expressing strong support for an option in a situation where
for example I'd been involved in helping draft the option.
And yet I wasn't faste enough on the email.
I think the same has happened to others.
So, I definitely  support social conventions to limit number of
sponsors, but I'd prefer not to have a hard and fast constitutional
rule.


signature.asc
Description: PGP signature

Do we want to Handle Secret Ballots in the same GR as Voting Changes

[Sam Hartman]

Russ made a final call for informal discussion.
I'd like to ask the community whether we'd like to handle secret ballots
now, or in a separate GR.

The rationale for handling things now is that we can get it done with
and if a controversial GR comes up, we'll have the option of secret
ballots if that's how we decide things.

The rationale for delaying is that it may make Russ's vote easier.
we may also have a large number of ballot options if there end up being
a significant number of amendments to Russ's proposal.

Here's what a simple proposal for making all votes secret ballot might
look like.
If we choose to  handle things this time around, someone (I'd be happy
to) could propose this as an amendment when Russ makes his formal GR.
I suspect Russ probably wouldn't accept the amendment just so we could
have both options on the ballot.
Given the discussions so far we'd probably have four ballot options
(secret ballots times  the two approaches to managing discussion
periods).



Resolved that the Debian Developers make the following changes to the
Debian Constitution:

4.1.3:
old:
3. 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.

new:
3. 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 public.  The voting period
   is 2 weeks, but may be varied by up to 1 week by the Project
   Leader.

rationale: I think we still want the ballots public because there's a
lot of useful analysis you can do on that.
Minimally state that the votes are not public without providing any
mechanism for how that works; that's up to the secretary.  There was
some discussion of using a DEP to provide specific mechanisms for
handling this; the secretary could of course take advantage of such
a DEP if it emerged.


4.1.6:
old:
6. Votes are cast by email in a manner suitable to the Secretary. The
   Secretary determines for each poll whether voters can change their
   votes.

new:
6. Votes are cast in a manner suitable to the Secretary. The
   Secretary determines for each poll whether voters can change their
   votes.

rationale:
Some of the systems being proposed for anonymous voting would work
better if they didn't need to use email.
Leave how that works up to the secretary.

5.2.5:
old:
5. 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.
new:
5. The next two weeks are the polling period during which Developers
   may cast their votes.

rationale: no need for a special case for leadership elections any more.


signature.asc
Description: PGP signature

Re: Towards more GRs

[Sam Hartman]

> "Felix" == Felix Lechner  writes:

Felix> Hi,
Felix> On Fri, Nov 5, 2021 at 2:45 PM Joerg Jaspert  
wrote:
>> 
>> I am pretty sure that was a 100% calculated move to go directly
>> to this.

Felix> It was impromptu. The mail was intentional only in the sense
Felix> that I hoped to find a topic to unite people. (Who likes
Felix> slavery, anway?)  Let's lose the fear of referendums. Our
Felix> fellow contributors are our trusted partners in this noble
Felix> endeavor!

We're in the middle of approaching what are  I hopo two relatively
uncontroversial referendums:

* A proposal to update our voting process (which looks like it will have
  a couple of options on the ballot)

* A proposal to have secret ballot votes as an option/requirement.

No action was required to get some practice with referendums that
hopefully will not be painful.

Re: Draft GR for resolution process changes

[Sam Hartman]

Charles>  - About the sponsors, if there are too many, then the
Charles> proposer is more at risk to face vetos when accepting
Charles> amendments.  (I write that as I accepted major changes as
Charles> the proposer of a GR option some years ago.)  Would it make
Charles> sense to limit the total number of sponsors, and to only
Charles> allow developers to sponsor one option ?

I don't understand this concern very well.
If some of your sponsors don't like an amendment you accepted you can
withdraw.
So long as you have k sponsors remaining, the option can stay on the
ballot.

What am I missing that leads to your concern?

Re: Renaming the FTP Masters

[Sam Hartman]

> "Timo" == Timo Röhling  writes:
Timo> I am fine with any name on which the FTP masters and the DPL
Timo> can agree, including the current one. I would also happily
Timo> ratify their choice via GR if they felt that the whole project
Timo> should have a say.  What I do not want is force a GR decision
Timo> upon them.
+1


signature.asc
Description: PGP signature

Re: Opposing strict time limits

[Sam Hartman]

> "Russ" == Russ Allbery  writes:
Russ> This analysis is very sensitive to the percentage of people in
Russ> the minority who would be willing to delay the vote.  I think
Russ> a more likely number (probably still too high) would be at
Russ> most 10% of the voters (a quarter of those in the minority),
Russ> which would allow 7 delays, or 21 days (3 weeks), for a
Russ> maximum discussion period of six weeks.

I did less math, but my intuition was the same.
My intuition was that you could probably get six weeks of delay for a GR
that some minority really didn't like.
Beyond that, I guess the political back pressure would be strong enough
to git rid of the delay mechanism after the triggering GR was dealt
with.

I don't think adding a maximum matters to me much because I think that
the practical maximum is somewhere between 6-9 weeks.

I definitely prefer Russ's proposal.

One concrete change I'd request would be language added  that said what
the delays should be used for.
Something like "Delays should only be used to provide time to develop
additional ballot options and not to delay the vote on a GR that those
seeking a delay find objectionable."
Such language, particularly if phrased with should language, has no
normative effect based on how the constitution defines should.

However, I think it might have behavioral effects in terms of setting
community expectations.
For example I could ask someone what ballot option they were working on
if they proposed a delay.
And if it was clear that they were not, our normal mechanisms for
approaching behavior inconsistent with our norms could be applied.


signature.asc
Description: PGP signature

Re: Opposing strict time limits

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:

Wouter> Can you shed some light on your opinion here? I've tried to
Wouter> build an option that I hope can achieve some form of
Wouter> consensus, and I would like to know whether I have succeeded
Wouter> in doing so. I don't think I'll change much if not, but it
Wouter> would be useful information nonetheless.

Russ's option has a maximum time for discussions.
Yours does not.

However, I think you've done a good job of coming up with counters for
most of the abuses that we thought of here, and so I think it likely
that your option would be a significant improvemement over the status
quo.

Re: Opposing strict time limits

[Sam Hartman]

> "Nikolaus" == Nikolaus Rath  writes:

Nikolaus> On Oct 22 2021, Wouter Verhelst  wrote:
>> I also believe that a ballot with options that were written by
>> people who do not support that option will usually result in a
>> cluttered ballot, with various options that are almost but not
>> quite the same thing, and options that are irrelevant noise and
>> which will never win. I think this behavior should be discouraged
>> if not outright forbidden (although, again, I'm not sure how to
>> forbid them),

Nikolaus> How about something like this?

Nikolaus> "My proposing or seconding a ballot option, every
Nikolaus> proposer/amender commits to rank this option above FD and
Nikolaus> (in case of multiple ballot options) higher than at least
Nikolaus> half of all the options. Should the proposer/amender's
Nikolaus> ballot not confirm reflect this at the time of the vote,
Nikolaus> proposer's/amender's vote will not be counted."

Wouter and I are going to disagree on this, but I actually think that
the work I did during the latest systemd vote significantly helped move
the discussion forward.  By trying to listen to various sides and trying
to present several options I think I managed to frame the process in a
way that was more constructive.

I'm sure that process can be refined.  But I'd rather see DPLs do that
work more rather than less.

I also don't want to see that work restricted to the DPL.  In many cases
I'd rather see ballot options drafted by people in the middle rather
than by strong proponents of a polarized position.


I'll note that it seems very likely that all the options I proposed
would have been preferred to FD.  (We don't quite know for sure because
Proposal C was withdrawn in favor of Proposal F).

The restrictions you propose would make this sort of framing the
discussion and putting together a slate more difficult, and so I think
it's a really bad idea because I think it takes away one of the tools
that shows promise in reducing conflict in Debian.

Even if you agree with wouter's goal, I think there are a couple of
problems:

1) Remember that we want to move toward secret ballots.
I think your proposal is either impossible to implement with secret
ballots, impossible to verify, or exposes enough information that it
would compromise secrecy.  That depends on exactly how the secretary
chose to implement secret ballots and your proposal.

2) Your proposal gets in the way of people changing your mind.  In
effect, you're asking people to lock in their positions.  That
contributes to the sort of polarization and conflict that I'd like to
see us avoid.

--Sam


signature.asc
Description: PGP signature

Re: Opposing strict time limits

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:
Wouter> However, the problem I see with strict timings that cannot
Wouter> be extended in any possible scenario is that we may end up
Wouter> with a situation where one option cannot be fleshed out
Wouter> entirely due to lack of time. I think it's unrealistic to
Wouter> assume that in such a case everyone can be convinced to
Wouter> postpone the vote by two weeks, *at least*, rather than
Wouter> extend the discussion time by a few days in order to allow
Wouter> the option that hasn't finished gathering enough seconds to
Wouter> finish up and become acceptable to enough people.

I think this is interesting to explore.
It's important to me that there be a maximum time that discussions can
last.
But I am open to the idea of being able to extend the discussion time
because you have k seconds interested in doing so even though you don't
yet have a ballot option.

I'll note that under Russ's proposal, you could do this by proposing a
ballot option like
"We'd like to explore mandating using rpm rather than dpkg, but need a
few days to flesh that out.  We will replace this ballot option before
the vote, but if somehow we don't, vote for this option if you'd like to
give us a chance to frame that in the next discussion."

That's clunky I grant you, and I'm definitely open to the idea that
rather than proposing a ballot option like that, k people could delay
the clock (but not more than the maximum discussion period) in order to
get an option onto the ballot.

Wouter> So what I think is important is to allow for a way to get a
Wouter> short amount of extra time, *once*, in order to finish up a
Wouter> proposed ballot option.

I think what I propose above gives you that.

Wouter> This could be accomplished as follows:


Wouter> The process can be repeated as
Wouter> long as the discussion time has not expired; but, crucially,
Wouter> anyone who seconded a previous extension request cannot
Wouter> second another one (although you can *request* another
Wouter> extension if you want).

Wouter> In practice this would mean that if you have a significant
Wouter> level of support for extending the discussion time, you can
Wouter> probably get the discussion time extended twice, and *maybe*
Wouter> three times if you're lucky, but I think it highly unlikely
Wouter> you'll be able to extend beyond that.

Interesting:-)
I'd have to think hard about whether to rank that proposal above or
below FD.
I prefer Russ's option, but given your goals I agree this sounds like a
good way to achieve them.

Re: Opposing strict time limits

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:
Wouter> I hear and agree with the argument against such a procedure;
Wouter> having a way to delay the vote which everyone can trigger
Wouter> opens the system up to abuse, which could allow the vote to
Wouter> be delayed indefinitely if formulated badly. I believe the
Wouter> answer to that is not to remove the option to delay the vote
Wouter> entirely, but to restrict the conditions under which such a
Wouter> delay can be invoked; only provide it to the DPL, or provide
Wouter> only a limited number of delays, or allow a majority of
Wouter> people who proposed options that are already on the ballot
Wouter> to object, or something along those lines. The goal should
Wouter> be to end up with a procedure where *can* extend the
Wouter> discussion period if discussions are actually still
Wouter> happening and we believe it is valid, without allowing
Wouter> people who want to avoid any vote from happening entirely to
Wouter> delay things indefinitely.

Wouter> Additionally, this proposal does not remedy what I think is
Wouter> another issue we have with our procedure, which I have been
Wouter> wanting to resolve one way or the other for quite a while
Wouter> but have no idea how to do so; the "I want to create a
Wouter> ballot with all possible options" antipattern.  We had a few
Wouter> cases of this over the years (at least two that I can
Wouter> remember), usually by well-intentioned people who want to
Wouter> get things to a vote quickly, but I honestly believe it
Wouter> creates more problems than it attempts to solve.

Wouter> Writing an option that does not represent your own personal
Wouter> opinion is extremely difficult at best, and is probably not
Wouter> even possible at all.  This means you'll get proposals from
Wouter> people who actually hold an opinion very close to what you
Wouter> wrote down that you'll then need to evaluate to decide
Wouter> whether this improves the ballot option, or whether it
Wouter> changes the option into something different entirely and
Wouter> thus should be a separate ballot option instead. To deal
Wouter> with such a proposal from the point of view of someone who
Wouter> feels one of the options is almost-but-not-quite something
Wouter> you can vote for can be very frustrating, as I experienced
Wouter> first-hand in
Wouter> https://lists.debian.org/debian-vote/2019/11/msg00032.html .

Wouter> I also believe that a ballot with options that were written
Wouter> by people who do not support that option will usually result
Wouter> in a cluttered ballot, with various options that are almost
Wouter> but not quite the same thing, and options that are
Wouter> irrelevant noise and which will never win. I think this
Wouter> behavior should be discouraged if not outright forbidden
Wouter> (although, again, I'm not sure how to forbid them), and
Wouter> would note that adding a strict time limit seems more likely
Wouter> to create private discussions (as I've explained above) and
Wouter> therefore to me seems more likely to result in this
Wouter> antipattern.

Wouter> I'm not submitting a formal draft to go against yours at
Wouter> this point (although I do have the beginnings of one),
Wouter> because I would like to see whether I'm alone in this
Wouter> opinion or not, where only in the latter case it would make
Wouter> sense to continue down this path.

Wouter> Thanks for your thoughts,

Wouter> [1] In the case of 2006-003, I started a discussion on -vote
Wouter> in order to start the debate before formally proposing a GR,
Wouter> intending to explore the problem before starting to build
Wouter> the ballot. The first follow-up to that mail however was a
Wouter> formal GR proposal by Manoj, which then started the
Wouter> procedure. It was not contentious vote though, and I think
Wouter> technically the vote may have expired at least once,
Wouter> although I'm not 100% sure about that -- it involved a few
Wouter> amendments resetting the timer and the DPL extending the
Wouter> minimum discussion period after one of them, so the details
Wouter> are a bit muddy.  [2] In 2006-005, Denis Barbier proposed a
Wouter> vote to recall the project leader. The DPL then delegated
Wouter> the authority to vary the discussion and voting periods to
Wouter> him and Loïc Minier. Denis chose to not accept any
Wouter> amendments and reduced the discussion time to the minimum,
Wouter> and called for a vote while, in my opinion, the discussion
Wouter> was still in full force.

Wouter> -- w@uter.{be,co.za} wouter@{grep.be,fosdem.org,debian.org}


I'm reluctant to engage here, because I disagree strongly with  Wouter,
and I don't think we're going to find consensus, and so at 

[Sam Hartman] Re: Draft proposal for resolution process change (v2)

[Sam Hartman]

Russ pointed out that I sent my message of support for the current
language about discussion timing only to him.
That's not very useful in terms of judging consensus, so here it is for
the list.

 Start of forwarded message 
From: Sam Hartman 
To: Russ Allbery 
Subject: Re: Draft proposal for resolution process change (v2)
Date: Fri, 08 Oct 2021 08:24:09 -0600

>>>>> "Russ" == Russ Allbery  writes:

Russ> I'm somewhat surprised that there has been no discussion of
Russ> the timing of the GR discussion period, which I expected to be
Russ> more controversial.  The scheme I'm proposing is relatively
Russ> complex but allows the discussion period to vary from 1 week
Russ> to 4 weeks based on how much ballot option activity there is
Russ> and based on DPL actions.  If anyone is unhappy with that (if,
Russ> for example, you think it's too complex or 4 weeks is too
Russ> short or too long), now would be a good time to bring that up
Russ> so that we can discuss it.

Russ> Even if you want to do someething entirely different that you
Russ> don't think I would agree with, I think it's worthwhile to
Russ> hammer out other ballot options now so there's lots of
Russ> opportunity for discussion and proofreading.


I think you strike a great compromise on the timing of discussion
periods.
There's a bit of flexibility available but the discussion period is
subject to a lot less manipulation  than under the current system.

Because there is a maximum discussion period and because all ballot
options are treated the same, I think the motivation for changing the
discussion period is smaller.

And yet we have seen cases for example  around one of the GRs dealing
with firmware where the discussion period was shortened and where there
was a complete lack of objection (at least in my reading of debian-vote
from the time).

So I think this is a good balance.
 End of forwarded message 


signature.asc
Description: PGP signature

Re: Draft proposal for resolution process changes

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> I've been thinking about this because I like the idea in
Russ> theory but can't see how to make it work in the process
Russ> without introducing new problems including tactical voting
Russ> issues.  I have also been wondering why it would be necessary
Russ> for the constitution to say this given that anyone can start a
Russ> GR and could choose to start a GR in this case.  In other
Russ> words, why does the GR need to be forced, as opposed to an
Russ> option that a TC member or any other Developer can exercise?

I had a todo item to write a message saying the same things.
I think the tactical voting issues are significant enough that we don't
want to mandate it in process.

But I think that the idea of using a GR to resolve a stuck TC is
compelling.
So, perhaps we as a project should come to a consensus that we strongly
encourage the TC to bring matters (especially where a casting vote
decides) to the project as a whole.

You have several former TC members (Russ, Bdale and myself) who believe
this is often a good idea.
And you have other developers including Adrian who have voiced support
for the idea.

Re: Draft proposal for resolution process changes

[Sam Hartman]

> "Bdale" == Bdale Garbee  writes:

Bdale> Russ Allbery  writes:
>> The process I'm proposing arguably favors the opposite side from
>> my own in the TC decision that primarily prompted this change and
>> would have prevented the process that indeed happened.
Bdale>...
>> But with the benefit of a few years of hindsight and watching
>> subsequent GRs, I think a simpler process with clearer rules and
>> less flexibility would have had a better social outcome for the
>> project.

Bdale> I think you're right.

Thank you for doing your part at that time to find a way to make Debian
better by actually making a decision that was before you and that many
had struggled   to make.

Nothing we're doing now takes away from the importance of the work you
did then and the sacrifice involved in making the decisions you did at
this time.
We live and learn and grow.
And sometimes that growth is painful, but when we can take that pain and
turn it into something that brings us together, that's something
amazing.

I'm honored to be part of a community with people like you who will make
those hard decisions when they are necessary.
I am honored to be part of a community with people like Russ who will
find ways to learn from the pain and  grow the community.


--Sam


signature.asc
Description: PGP signature

Re: Draft proposal for resolution process changes

[Sam Hartman]

> "Felix" == Felix Lechner  writes:

Felix> The constitution's projection of hardened confrontation
Felix> entails a terrible reflexivity: A 3:1 supermajority leaves no
Felix> gray area. There is no gentle nudge and no room for
Felix> measurement. The maintainer was so wrong, fixing it required
Felix> the second-worst measure in the Debian universe. (Expulsion
Felix> being the most drastic.) No defeated maintainer will go to
Felix> bed that night. thinking "well I lost, but it was a close
Felix> call." I would like to give the system more wiggle room.

Felix, one of the things I've learned to value both from software and
from politics is the idea of incremental improvement.

I very much would love to find ways to avoid hardened conflict.
You can see that in my rationale for resigning from the TC, in my
comments on finding compasion, and in my comments on thoughts about
revising the structure of the TC.

And yet, I think those changes are going to be larger.
I'd love to see us accomplish them.
I'm struggling trying to write a note to debian-private asking how we
managed to turn down a path of conflict rather than a path of
cooperation.

But I think those larger changes will take time.
And I think Russ's changes will make the process more fair and will
remove some potential obstacles for making those larger changes in the
future.

If I commit to continuing to work toward building a Debian with more
compassion and cooperation and less conflict, would you join me in that
work later and not stand in the way of this incremental improvement?

Re: Draft proposal for resolution process changes

[Sam Hartman]

> "Russ" == Russ Allbery  writes:
Russ> I don't recall the "when the outcome is no longer in doubt"
Russ> provision having been a problem in the past, so I admit my
Russ> bias is towards fixing the wording but maintaining the current
Russ> process.  I'm not sure there's a need for a change.

I support this approach.  I think if at any point the outcome is no
longer in doubt assuming no future actions, the vote should terminate.

In regard to a couple of other issues that have been raised:

* I find Carsten's message about tactical voting compelling.  I had
  almost been convinced to support removing the casting vote from the
  TC, but I think the argument Carsten's raises is good.  So I support
  keeping the casting vote.


* With regard to the issue of the long corner case and a member
  objecting to a TC call for vote late in the process... I note that we
  have seen calls for vote used tactically within the TC.  I hope we
  want to avoid that in the future, and given that  we've already seen
  tactical calls for votes happen, we should focus on corner cases
  involving them.
  In the particular case of a tactical call for votes on the TC
  (systemd), this corner case would not have mattered.  Even so, I think
  it is worth the language to fix.

Re: Draft proposal for resolution process changes

[Sam Hartman]

> "Russ" == Russ Allbery  writes:
Russ> Procedurally, I don't believe we should automatically start a
Russ> GR because I think there's benefit to going through the normal
Russ> GR process.  For example, who is the proposer of the GR for
Russ> the purposes of making subsequent ballot option changes?  This
Russ> special type of GR would add a bunch of complexity that we'd
Russ> have to spell out, and I don't think it's worth it.
I agree with you that a GR should not automatically be triggered.  The
TC may want to word the GR differently, and it may be obvious that some
of the options on the TC ballot do not need to be proposed in a general
GR.


However, I think we already have the complexity you are worried about:
4.2.1 permits both the DPL and the TC tto sponsor a resolution without
additional developers.

I think that it's not too hard to make this useful.
Under section 6.3,
say something like
"When the Technical Committee proposes a general resolution to the
project, it may delegate the authority to accept amendments and withdraw
ballot options to one of its members."


If the TC didn't choose to delegate such authority, it would presumably
have to vote on amendments.

In many cases, I think individual TC members will find it easier to
simply propose a resolution themselves.  However, I think there are
cases where having the TC bring an issue to the project could lend
legitimacy to the decision making process and I would prefer not to
remove this power from the TC as part of this process.

--Sam

Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result

[Sam Hartman]

>>>>> "Bdale" == Bdale Garbee  writes:

Bdale> Sam Hartman  writes:
>> The math certainly helps.  We can easily see that even if we
>> think that kind of strategic exploration is not an abuse, it
>> clearly would be an abuse if some privileged category of people
>> got to choose the ballot options.

Bdale> The sensitivity of preference-based voting systems to
Bdale> strategic influence would seem to be related to the number of
Bdale> active voters.  The typical Debian GR has enough valid votes
Bdale> that this isn't something I've ever actively worried about in
Bdale> the context of a GR.

Here, I think we're talking about the ballot options influencing the
vote rather than influence within the ballot.

Basically If I can create an option that might cause the voters to
discover a cycle were it on the ballot, I can potentially influence the
result.

It's not obvious to me how having more voters makes that harder to do.
In the last election, i think it is fairly obvious that a cycle is more
likely with the ballot we had than a simple up/down vote.  I don't think
it was particularly hard to guess that adding options to the ballot
increased the likelihood of a cycle.

I don't think the cycle became less likely as the number of voters
increased.  At least it's not obvious to me why that would be the case.


And yet, in this instance at least, I think that cycle accurately
reflects voter thinking.  If you force people to choose a simple yes/no
answer, you're likely to get a yes/no.  But if you allow them to express
something more complex you might well find that the preferences of the
community overall do not form enough of an ordering to have a clear
winner.

That almost happened to us.
And yet I don't think that asking a simple up/down answer would have
gotten us a more correct understanding of Debian's feeling on the issue.
It would have gotten us a  easier to interpret answer, but I think it
would have overlooked complexities important to the voters.

Sigh, I guess this turned into an opinions differ on the value of asking
simple questions message after all.  I didn't intend to write such a
message, and probably wouldn't have written such a message to you,
because I know we've discussed the issue and understand each other well.
I'm sending it, because at least for me, this message helps me capture
the proes and cons of asking simple questions vs having a lot of
overlapping ballot options better than I have previously.
I hope others find it useful too.  I'm definitely not trying to drag you
into a discussion we've had before.

I also recognize I probably have some unstated biases that cause me to
believe that the complex answer with the higher probability of cycles is
more reflectie of actual voter thinking.



signature.asc
Description: PGP signature

Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result

[Sam Hartman]

>>>>> "Barak" == Barak A Pearlmutter  writes:

Barak> On Wed, 21 Apr 2021 at 16:57, Sam Hartman  
wrote:
>> That's a big jump, and I don't think I agree.  At least not when
>> you phrase it that way.  Why should my preference matter less
>> just because it's weaker?  It's still my preference and I'm
>> attached to it very much:-)

Barak> There are two ways to approach this kind of question.

Barak> First: we can use our intuitions. What makes sense? And we
Barak> can discuss that, explain why some things seem intuitively
Barak> fair and others don't.  We can make analogies. How does a
Barak> group decide on a restaurant? What do we think is fair? What
Barak> doesn't seem fair?

Barak> Second: we can get scientific about it. This means we define
Barak> some performance metrics for voting systems, then measure
Barak> their performance. Such measurements can be done
Barak> theoretically, or in simulation, or in practice. It can use
Barak> various assumptions about the environment, and even various
Barak> performance metrics. This might include difficulty of filling
Barak> out a ballot, or understandability of both the ballots and
Barak> the system as a whole, as part of the performance. When we
Barak> try it on real people, factors like what fraction of the
Barak> eligible voters actually bother to vote, or what fraction of
Barak> them can correctly answer questions about how the system
Barak> works, might be things to measure.

Thanks for bringing this up.  This was the one part of the conversation
 I didn't get to touch on in my last message, and I think it's the last
 lose loose end of the conversation.

I actually find that the scientific part of the conversation is not
helpful to me in determining what the requirements should be--what the
desirable properties are.

As an example, I am finding this conversation very difficult to follow,
because you are always phrasing things in terms of alpha, beta, and some
generic options.
I appreciate given the past few weeks why you're doing that--the
discussions have been charged.

While I find that our track record with intuition is bad, it's very easy
to get into the mathematical land with bad requirements and have high
confidence in a system that doesn't meet our needs.

Let's take an example of something you brought up early on: in our
voting system, the outcome can change when a ballot option is added.
If I think about that in terms of generics, it sounds like a horrible
property.

But as I start to think about that with specific analogies, I realize
that it's actually related to  situations that come up in consensus
decision making.
And when I restate it as something like  the following, it's much less
clear that it is an undesirable property.
Sometimes new information from the voters can influence the outcome of
the decision making process.  If we end up asking about an outcome that
fits into the middle of a cycle between other outcomes, we have more
information, and this information can change the result.

And once you look at things that way, it becomes  a lot less clear
to me at least whether that's an undesirable property.

And no, thinking about strategic abuses isn't going to help much.  Are
those really strategic abuses, or are we saying that people who can
introduce options that allow us to better determine the voter
preferences can successfully influence the election?
That is, is it strategic abuse, or strategic examination of the voters
desires?
The math has its place, and may even help us think about that question,
but it's not going to answer it for us.

The math certainly helps.  We can easily see that even if we think that
kind of strategic exploration is not an abuse, it clearly would be an
abuse if some privileged category of people got to choose the ballot
options.

So, for me, I've been finding participating in this discussion difficult
because of the mathematical emphasis.  It's not that I can't follow the
math.  It's that divorced from the analogies, I cannot reason about
whether our initial requirements are any good nor reason about trade
offs between them.

--Sam


signature.asc
Description: PGP signature

Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result

[Sam Hartman]

>>>>> "Barak" == Barak A Pearlmutter  writes:

Barak> On Mon, 19 Apr 2021 at 16:35, Sam Hartman  
wrote:
>> I think we need voting reform around how the amendment process
>> works and managing discussion time ...  ...  Preferences can be
>> of different strengths.    Which is to say that the gaps
>> between preferences might be relatively weak.

Barak> Sam, you make an excellent point about gaps between options,
Barak> and that a ranking does not show the strength of
Barak> preferences. Like, I might prefer ALPHA >>> BETA > GAMMA
Barak> while you prefer ALPHA > BETA >>> GAMMA.

We agree so far.

>So if it's down to
Barak> ALPHA vs BETA, my vote should shift things more than yours,
Barak> while if it's down to BETA vs GAMMA, your vote should shift
Barak> things more than mine. And

That's a big jump, and I don't think I agree.
At least not when you phrase it that way.
Why should my preference matter less just because it's weaker?  It's
still my preference and I'm attached to it very much:-)
You then later talked about a voting system in which we somehow assigned
numerical scores to the result.  I'll admit that as a theoretical
exercise I'd love to explore something like that.
I think it would be years before it could be debugged, and reviewed, and
all the weaknesses explored enough that I'd want to consider it for
Debian.

I was actually trying to say something different.
I think we're debating about what properties our voting system should
have now.
I think we've left the math behind a while ago, and are debating what's
desirable.
My claim is that  our voting system seems to do the following:

1) Ignoring super majorities, if there is a winner of the pairwise
elections, we choose that as the winner of the election.  I think no one
has disputed this as a desirable property.  People have argued about
whether they'd be willing to give up this property to get something
else,  but I think at least in this discussion this has not been
controversial as something we desire.

2) We let voters indicate whether they consider an option acceptable.
That is we let them decide whether they would prefer that option be
selected or whether they would prefer the decision making process
continue.  We never select an option if most voters would prefer to
continue the decision making process  to selecting that option.

3) If there are options that   a sufficient number of voters (often a
simple majority) prefer  to continuing the decision making process, we
will pick one of those options.  There are several points in the process
where the desire to pick an option if there is one that defeats FD is
strongly encoded.

4) No really, we're quite serious about wanting to be done if there is
something that a majority of the voters consider acceptable.  So much so
that there are situations where we'll pick a less preferred option just
to be done because the more preferred option  requires a supermajority
it didn't meet.  As an example, we might pick a simple statement over a
constitutional amendment even if more people prefer the constitutional
amendment.  This is only interesting if a majority of voters consider
both the constitutional amendment and the simple statement acceptable.
The simple statement gets picked rather than the constitutional
amendment if it was not preferred by a sufficient super majority of
voters.

And yes, I have high confidence that the above were intentional
decisions.  We may disagree; we may change our minds.  But this has all
been debated time and time again, and for the most part on these aspects
of the voting system people were aware.
And certainly by the time we considered revising the voting system (I
think that was around 2003) we were very aware of these issues.

My take away is that the voting system is designed with an implication
that there is a huge preference gap between acceptable and unacceptable
options, and that by the time the GR procedure is called into play, it's
better to have a decision if that is at all possible.

That certainly mirrors my experience as a voter.
I generally find I am able to find a line of acceptability on most of
our ballots.
And I find that above that line I really would be  able to  accept any
outcome.
Yes, I want my vote to be counted.
And if there is a pairwise winner, I want that.
But if there is a cycle, well, okay, pick something.

We have a strong history of being able to get "no statement" options on
the ballot when we need them.
People aren't afraid to vote for them.
This is at least the second election where such an option won.


signature.asc
Description: PGP signature

Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result

[Sam Hartman]

> "Jonas" == Jonas Smedegaard  writes:

Jonas> Quoting Barak A. Pearlmutter (2021-04-20 16:12:16)

Jonas> Maybe it makes sense to e.g. add a friendly notice in the
Jonas> voting confirmation email when not all voting power is used.
Jonas> But there is already a lot of text surrounding a vote, so
Jonas> such noticemight commonly be missed.

I support this and thank Adrian for convincing me of the value.
I don't support going as far as Adrian appears to want to go and
rejecting ballots that fail to rank all choices.

--Sam

Re: Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result

[Sam Hartman]

> "Barak" == Barak A Pearlmutter  writes:

Barak> The Schwartz set resolution algorithm is absolutely best of
Barak> breed. But there's an old saying in computer science: garbage
Barak> in, garbage out.

Barak> If we look at the actual ballots, it's really
Barak> interesting. Options 7 and 8 were semantically pretty much
Barak> equivalent. It's hard to see any reason for someone to rank
Barak> them very differently. So if the voters are rational, we'd
Barak> think that nearly all ballots would have options 7 and 8
Barak> ranking either the same or adjacent. And that if one is
Barak> ranked the same as other options, then they should both
Barak> be. Yet many of the ballots rank one but not the other, or
Barak> rank them very differently.  Some voters ranked either option
Barak> 7 or 8 as "1" and allowed everything else to default. It's
Barak> very difficult to imagine someone who actually preferred
Barak> option 7 being equally satisfied with any of options 1-6 and
Barak> 8.


In my mind the ballot options are not similar.  First, things above FD
are things I don't mind being in a cycle.  If it's ranked above FD, I'd
rather be done with a decisdiscussion and have that option win even if
it is not my preferred option.  Options below FD are options I'd prefer
not make their way into a cycle.

Second, FD implies that the question is still open.  I might be able to
convince people to choose something more aligned with my option in the
following discussion.
In contrast, option 7 is final; we've made a decision.

So, in filling out my ballot I rank:

1) Options that I like--where I'd be okay with any of those options
getting chosen.

2) fd

3) Options that are in the general direction I like, but are weak enough
that I'd rather have an opportunity to ask people to do something
stronger than choose those options.

4) no statement

5) options that are in a direction I disagree with.

Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result

[Sam Hartman]

I'm writing to present an alternate interpretation--the one under which
I think our voting system is doing a good job of choosing among complex
ballots in the last couple elections.
I think we need voting reform around how the amendment process works and
managing discussion time, but I am very happy with how the actual voting
mechanism  has worked.
That's true even though my preferred option didn't win in either the rms
election or the systemd election.

> "Barak" == Barak A Pearlmutter  writes:

Barak> If the winning option in an election is part of a preference
Barak> cycle, then it (by definition) has the property that there
Barak> exists some other option that a majority of the voters
Barak> preferred. In some elections that is unavoidable: we need to
Barak> pick one DPL, and if they're in a cycle so be it; if there's
Barak> a tie we can just toss a coin. But in others, like the RMS
Barak> GR, it seems like it would be a rather bad property and we'd
Barak> be better off treating it as FD and trying again later.

Barak

Preferences can be of different strengths.
Imagine we were using the Debian voting system to decide where to go to
dinner before a conference in six weeks.
It might well be that we had five or six options that were generally
acceptable to most people (and perhaps a couple options that were
unacceptable that got dropped).
We don't have to go to dinner, and we don't even have to use the voting
system to make our decision.
So, unlike the DPL election, a decision is not necessary.
And yet, I suspect many people might well prefer to be done with things
and to have a decision even if there is an option that a majority of
voters prefer  to the selected option.
Which is to say that the gaps between preferences might be relatively
weak.

I think we've tried to encode that in our voting system with the
majority requirement.
We never select options that the voters consider unacceptable.
And among the options that the voters do consider acceptable (if any),
we'd prefer to make a decision than not to make a decision.

Consider for example if we had a cycle between options 2, 3 and 4.
That would be a clear desire to make some sort of statement, and the
debate would be over how strong of a statement to make.
I don't think we would be well served in such a situation to make no
statement at all.

It gets more complex when you add option 7 (the no statement option)
into the cycle.

For me though, even there, notice that we'd be choosing between options
that the voters considered acceptable.
Because of that, I am not bothered by the cycle.



signature.asc
Description: PGP signature

Re: What does FD Mean

[Sam Hartman]

> "Gunnar" == Gunnar Wolf  writes:

Gunnar> I would not like to remove the expressive option of stating
Gunnar> '-' as a synonym to "below all other options".

We are in agreement.
However, I think Adrian has made a point that there are some non-obvious
consequences if you don't fully rank a ballot.
For example, failing to rank  FD has effects you may not intend.
12 is more likely to be intended than 1-
Both are valid votes.
And yeah, I've intentionally ranked FD the same as something else
before.

But I think you are less likely to confuse yourself if you rank
everything.
So my preference would be to:

1) Recommend people rank everything

2) Continune to specify what happens if they don't.

3) Continue to accept ballots if they do not.

Re: What does FD Mean

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:

Adrian> My suggestion would help people to make full use of their
Adrian> vote by forcing them to rank all options.

Adrian> Equal ranking is still possible, it would not remove your
Adrian> freedom to rank any number of options equally.

I'd support revising the instructions to recommend that voters rank all
options on the ballot.

I don't support mandating it.
If someone doesn't rank an option I'd rather accept a ballot than reject
it.
If someone wrote a patch to warn people if they sent in a not fully
ranked ballot, I'd also support that.
I just prefer to accept as many votes as we can rather than
disenfranchising people.
But I agree that fully ranking the ballot is likely to avoid surprises.

--Sam

Making the RMS resolution a Secret Ballot

[Sam Hartman]

On another list, there was discussion of the DPL encouraging the
secretary to make the vote on the rms GR secret.

I'll let the DPL speak for his own position.

A bit of background.

There has been increasing harassment of people based on what they are
expected to vote on the rms gr.
People on both sides have expressed increasing discomfort with the idea
of voting in public with the entire world knowing how they voted.

I argued on another list that it would be appropriate for the DPL (with
the concurrence of the secretary) to  make the vote secret using
constitution section 5.1 (3).
Here's my rationale:

Thanks for doing this.  I'm actually very comfortable for us to make the
decision under 5.1(3).  We cleraly cannot hold a GR in time to change
the constitution prior to the election ending.  And our constitution
already has a provision for making decisions where a timely decision is
required.  I think this qualifies; it is becoming more and more clear we
need to protect people on both sides of the vote, and other avenues like
GRs will not allow us to achieve something in time.  This is not a
situation that has become urgent through inaction on our part: as
harassment has increased it has become more clear that action is needed.
So while we might have been willing to let this last vote slide without
secret ballots, it is becoming more clear through the actions of others
that is an increasingly bad idea.  So I absolutely support the DPL (with
the secratary's concurrance) making this decision under the emergency
powers DPL clause.

I am very uncomfortable with the other rationales for making the
decision--using various loopholes in the constitution.

It's pretty clear that's not what was meant by the text of the
constitution.
And unfortunately, choosing to interpret the constitution creatively
like that to meet the needs of the day is a very slipperly sloap with a
lot of negative long-term consequences.

I like that for the most part we use plain language and common sense.
I would not like to see us twisting our language to meet the needs of
the day.
Especially when we have a clause already in our constitution  for making
emergency decisions.

Let's be honest about this and make this as an emergency decision
because we are in an emergency.

If we're going to solve this long term, let's do it by GR, not by
suddenly interpreting the constitution differently than we have for
years.



Several people agreed with me, ande one person disagreed.
I'll let any of those people speak up if they choose and let the DPL
comment if he chooses.


signature.asc
Description: PGP signature

Re: What does FD Mean

[Sam Hartman]

> "Adrian" == Adrian Bunk  writes:


I don't know.
I can totally believe that someone wouldn't quite have the stomach to
actually say that they prefer  more discussion of systemd.
I actually think 1--- is a reasonable vote.
And yes, I understand you are not expressing  a preference between the
unranked options than fd.
It's possible they meant 1--2, but it's possible they did not.
It's possible they meant 1223 as well.

i think it's very presumptuous to assume  anything about what someone
should have voted because all those combinations are reasonable.

Re: What does FD Mean

[Sam Hartman]

> "Timo" == Timo Röhling  writes:

Timo> * Mathias Behrle  [2021-04-03 10:22]:
>> [ ] Further discussion [ ] Do nothing, leave the question
>> unresolved [ ] None of the above

Timo> The way I see it, all these have the same consequence for a
Timo> vote (that is, none of the other options is acceptable). The
Timo> Constitution will always permit another vote as long as K+1
Timo> developers introduce/sponsor it. And anyone who feels
Timo> particularly strongly about continuing/terminating the
Timo> discussion, will probably post it to debian-vote no matter
Timo> what.

I agree.
Also, as someone who has been in the position of interpreting votes,
having these options on the ballot would actually make that harder in
some cases.

Re: What does FD Mean

[Sam Hartman]

> "Mathias" == Mathias Behrle  writes:

>> But for a two option situation, option A do the thing and option
>> B FD, FD probably does map to no fairly well.

Mathias> I would really like to avoid this situation, where FD is
Mathias> expected to leave room for such wide interpretations,
Mathias> especially if it is avoidable as easy as to put at least
Mathias> some of the alternative options on the ballot. A ballot
Mathias> with only 'yes' and 'FD' should IMO just not happen.

I think it's fine in cases where you have fairly strong confidence that
yes will win.
Let's say that for some reason we really needed a project statement that
the GPL was a DFSG-free license.
I think yes|FD would be fine.
Or for an example that actually happened, we needed a GR to replace
chairman with chair in the constitution.
In that case, I think yes|FD is fine.

Because if somehow FD wins, it's going to be a surprise.

I do agree that when we can articulate it, a terminal response like "do
nothing," is worth having on the ballot *if five people actually support
that*.

In the case of the current GR, I think we do have a wide range of ballot
options.
I'm reasonably sure that if FD wins it'll be because there's a
split--people would rather have the question remain open than see their
side lose, but no side can get a majority.

I'm not sure that you can capture an option other than FD in such a
situation.
"do nothing," is not actually the same as leave the question unresolved.

--Sam

DD vs DM and debian-vote

[Sam Hartman]

> "Salvo" == Salvo Tomaselli  writes:

>> I sincerely think debian-vote should be read-only for non-DDs
Salvo>   because this person is not a DD (afaict) and is just
Salvo> polluting our list with such non-sense.


Salvo> There are non-DD people who maintain more packages and with
Salvo> higher total popcon than DDs, but aren't DD because didn't
Salvo> bother to jump through all the several hoops to become a DD.

Those "hoops" are precisely about the broader community stuff that
matters when setting direction for the community as a whole.

If you want to contribute to the community by maintaining packages,
that's great.
To a large extent you generally get significant autonomy within your
packages.

But if you want to be part of deciding Debian's direction, or have
authority cross-package (NMUs, upload to new, etc), you need to be a DD.
Some of those hoops are exactly about judging your communications
skills, and are very much relevant for debian-vote discussions.

Yes, it takes work to go through the AM process.
I don't think it's unreasonable to ask you to take on that work if you
want a voice in debian-vote.

The AM process is quite efficient these days.
We've had a couple of times in the last month where we had free
application managers and were able to start the process as soon as all
the requirements were met.
We've had several processes lately take less than a month to complete.

What does FD Mean

[Sam Hartman]

> "Mathias" == Mathias Behrle  writes:

Mathias> I don't get that. Is this really common sense that FD
Mathias> means/meant "preserve status quo"? For me voting this
Mathias> option definitely should mean that further discussion on
Mathias> the topic is needed.


So, that is the denotation--that's what it literally means.
In cases where things are thoroughly discussed to death, especially
where it appears like all the options are on the table, it may well be
that there is not momentum for further discussion, and FD acts a lot
more like "no".
It's a kind of no that allows someone to try and find a future option.
It's more like "no not this moment," than "no and it would be rude to
try and discuss more."

But for a two option situation, option A do the thing and option B FD,
FD probably does map to no fairly well.

In this situation, I think we'd have to look for the spread of votes.
FD winning would probably either mean  that we actually need to have
further discussion (if a majority of people seemed to prefer one of the
options to others, even though they ranked it below FD), or the project
is too split to decide (if there were major splits below FD).

In the first situation, I'd interpret it to mean that there was one
direction that most people tended toward but that the specific option
presented was not good enough.
And so if there were energy, it would make sense to refine that option.

But in the second situation where there were significant splits in
support below FD, probably we ought conclude we don't have support for a
common direction.

So, yeah, FD is complicated:-)

As a Reminder Someone Needs to Call for Vote

[Sam Hartman]

As a reminder, we're past the minimum discussion period.
At this point, anyone who has proposed or seconded something on the
ballot can call for a vote.
The secretary may add delay for example so votes start on the weekened.


My general opinion is that someone should call for a vote at this point,
but I've been mostly on vacation and I'm not up to date enough to be
confident that would be the right call.
So I won't do it myself.



signature.asc
Description: PGP signature

Re: Asking DPL to shorten Discussion Period for rms-open-letter

[Sam Hartman]

> "Milan" == Milan Kupcevic  writes:




Milan> An official Debian statement is not about any particular
Milan> individual but about Debian's interests and goals.

Yeah, but in general, I find persuading people to change their minds on
stuff like this to be a waste of list time.

If someone is interested in a particular question in order to decide how
to vote, I find that to be a compelling argument in many cases to
continue discussion.

If there is no one who is likely to change their vote, and if the
positions are well understood, I'm going to do what I can to encourage
less email traffic on the issue.  By saying that I cared about one
question and not another, I was doing several things:

1) Letting Jonas know where his energy in discussing further might be
valuable at least as directed to me.

2) Letting everyone know that I was thinking about whether adding more
messages was helpful.

3) Trying to discourage people from arguing the legal question with me
because I'm not open to persuasion on that point.  If there is someone
else who considers that question live, engage with them.
Don't waste your or the list's time engaging with me on a question where
I've already made up my mind.
I won't stand in the way of you discussing that issue with someone who
is either trying to decide how they feel or who is trying to understand
the issue.


Milan> There is no space for emotional revenge punches in
Milan> the name of Debian.

I agree with the above but don't believe the authors of the letter see
it as an emotional revenge punch.
I don't see it that way either.
I'm still considering  whether

1) Making an unnecessary accusation is inherently shaming

2) Whether this letter is something I'd consider an attempt at shaming
(something I reject) or an attempt at public accountability (something I
often embrace)

3) Whether the accusation is unnecessary.


I appreciate that other people may view the situation differently, and
am in no way trying to imply that my view is the one that should drive
the conversation.  I do think it's reasonable to consider my view when
you're trying to decide whether interacting with me is worth your and
the list's energy though.  At this point in the process, I also do think
it's valuable to have a specific audience in mind when you write a
message and to think about whether your audience will find the message
useful.

--Sam

Re: Asking DPL to shorten Discussion Period for rms-open-letter

[Sam Hartman]

> "Jonas" == Jonas Smedegaard  writes:

Jonas> Quoting Pierre-Elliott Bécue (2021-03-28 20:31:01)
>> Le dimanche 28 mars 2021 � 14:04:48+0200, Jonas Smedegaard a
>> �crit�: > My involvement in this subthread was when Molly arguing
>> that the > accusation was not harmful (using other words, yes,
>> and we can > nitpick that if really necessary).  You (and others,
>> privately) > agree that the accusations are deliberately harmful
>> but that the > harm cannot backfire on Debian.  I have raised my
>> concerns - I rest > my case.
>> 
>> Accusations are generally harmful, and as accusations are always
>> delibeately made, they indeed tend to be deliberately harmful.
>> 
>> That does not mean they are not warranted. And I think it is that
>> point that could/should be discussed.

Jonas> Text #1 oncludes an accusation.  Other proposed texts does
Jonas> not.

Jonas> I think the relevant thing to discuss is not if the
Jonas> accusation embedded in text #1 is warranted, but instead if
Jonas> that accusation is necessary.  Is the accusation needed for
Jonas> that proposal?  It seems to me that the message would be the
Jonas> same with that accusation omitted, but maybe I am missing
Jonas> something.

There were a lot of messages here, and I may have missed some.

When I last paid attention to this, you were concerned about whether the
letter was an attempt at public shaming.
As a personal choice, I reject shaming fairly strongly.
But now somehow the discussion has moved on to whether  the accusation
in the letter is necessary and whether Debian risks  legal issues by
signing on.

The legal question is not interesting to me; I think the risk to Debian
is one I'm quite willing to accept.

But the shaming question is interesting to me (at least under my fairly
narrow definition of shaming).
I'd like to see if I'm understanding your argument.

Are you saying that by making an unnecessary accusation we would be
shaming?
And so you'd like to understand whether the accusation is necessary to
understand whether we are shaming?

--Sam

Re: Amendment to GR on RMS rejoining FSF

[Sam Hartman]

> "Sruthi" == Sruthi Chandran  writes:

>> 
>> Under section 4.1.5 of the constitution, the Developers make the
>> following statement:
>> 
>> *Debian’s statement on Richard Stallman rejoining the FSF board*
>> 
>> We at Debian are profoundly disappointed to hear of the
>> re-election of Richard Stallman to a leadership position at the
>> Free Software Foundation, after a series of serious accusations
>> of misconduct led to his resignation as president and board
>> member of the FSF in 2019.
>> 
>> One crucial factor in making our community more inclusive is to
>> recognise and reflect when other people are harmed by our own
>> actions and consider this feedback in future actions. The way
>> Richard Stallman announced his return to the board unfortunately
>> lacks any acknowledgement of this kind of thought process. We are
>> deeply disappointed that the FSF board elected him a board member
>> again despite no discernible steps were taken by him to be
>> accountable for, much less make amends for, his past actions or
>> those who have been harmed by them. Finally, we are also
>> disturbed by the secretive process of his re-election, and how it
>> was belately conveyed [0] to FSF’s staff and supporters.
>> 
>> 
>> We believe this step and how it was communicated sends wrong and
>> hurtful message and harms the future of the Free Software
>> movement. The goal of the software freedom movement is to empower
>> all people to control technology and thereby create a better
>> society for everyone. Free Software is meant to serve everyone
>> regardless of their age, ability or disability, gender identity,
>> sex, ethnicity, nationality, religion or sexual orientation. This
>> requires an inclusive and diverse environment that welcomes all
>> contributors equally. Debian realises that we ourselves and the
>> Free Software movement still have to work hard to be in that
>> place where everyone feels safe and respected to participate in
>> it in order to fulfil the movement's mission.
>> 
>> 
>> That is why, we call for his resignation from all FSF bodies. The
>> FSF needs to seriously reflect on this decision as well as their
>> decision-making process to prevent similar issues from happening
>> again.  Therefore, in the current situation we see ourselves
>> unable to collaborate both with the FSF and any other
>> organisation in which Richard Stallman has a leading
>> position. Instead, we will continue to work with groups and
>> individuals who foster diversity and equality in the Free
>> Software movement in order to achieve our joint goal of
>> empowering all users to control technology.
>> 

I took a break from debian-vote to deal with personal stuff and to work
on RC bugs.
I told Sruthi I'd come back the next day and second.
Looks like that is no longer necessary and I don't want to make extra
work for the secretary.
Thanks for putting this option together.
I'll definitely vote it above FD.


signature.asc
Description: PGP signature

Re: General Resolution: Richard Stallman's readmission to the FSF board

[Sam Hartman]

> "Dominik" == Dominik George  writes:

Dominik> With all due respect to everyone who has been offended by
Dominik> Richard Stallman, feels oppressed by him, or is negatively
Dominik> affected by his views — every single such person has to be
Dominik> heard, their fears and sorrows been taken into account, and
Dominik> appropriate action been taken.  As such, I am in full
Dominik> support of requiring the FSF board to instate an
Dominik> investigation committee, take letters from anyone affected,
Dominik> and hear these cases (including rms' position).


The problem is that for good reason, we no longer trust the FSF under
its current governance to do that.  What you are affectively asking
people to do is to pursue justice in regard to things rms did in a forum
where rms has much more power than they do and where rms (and the voting
members of the fsf) have demonstrated they will use that power in non
equitible ways.

Given how rms returned to the board, how can you possibly think those
people will get a fair hearing.

I think I may disagree with this option even more than the support rms
open letter option.


signature.asc
Description: PGP signature

Why does Debian Care about the FSF

[Sam Hartman]

> "Roberto" == Roberto C Sánchez  writes:
>> 
Roberto> Did Richard Stallman make an application to become a Debian
Roberto> Maintainer or Debian Developer?  It is not clear how
Roberto> Richard Stallman is "included" in Debian in such a way that
Roberto> it would even make sense to move to exclude him.

Debian works with (or at least has worked with) the FSF in the past.
We've invited people speaking in official FSF roles to our conferences.
We've had people interact with them in their events and when working on
maintaining their software and other things.

Many of us believe the FSF is not creating a safe, welcoming space.
We believe that they are making a strong statement by allowing rms to be
on their board , and we hear that statement as inconsistent with
creating a safe, welcoming, respectful space.

How does this impact Debian.

Imagine I'm mentoring someone and they find a bug in an FSF project.
If it was a bug in a project with an upstream  that created a safe
environment, I'd probably as a mentor encourage someone to submit the
bug upstream.

With the FSF or another project that I don't think will respect my
mentee, I'm going to focus more on that than getting the bug fixed.

There are thousands of other cases where this sort of trade off happens.
One of the big ones is the overall perception of the free software
community.
Because the FSF enjoyed such a prominent position in the community, when
they stumble, at least now, it brigs us all down.
People experience the FSF and paint all of us with that brush to a
greater or lesser degree.
And they should.
If the larger community doesn't police the organizations that make it
up, people should take that into account when they decide whether to
associate with us.

We are debating whether the FSF has done something strong enough that
Debian as a whole should ask the FSF to fix it and distance itself from
the FSF until they do.
It's appropriate for Debian to consider that as a project because at
least one side argues that being closely associated with the FSF is
inconsistent at this time with goals Debian has adopted as a project.

I think Debian should distance itself.  You may disagree.
But I hope you can see from my viewpoint why it's a reasonable question
for Debian as a project to answer.
Obviously if you view things differently, you can vote your conscience.

>> Labor rights are entirely different from "freedom of
>> association".
>> 
Roberto> Got it.  We can discriminate, but they can't.  Seems a
Roberto> touch irrational.

Oh, come on, you can do better than that.
I'll admit that Steve is being a bit simplistic and viewing things with
a bit more black and white than I like.
But try this on.

Freedom of association, freedom of speech, labor rights, all that are
*complex* and *intertwined*.
Take the union example.
In my country, employers generally can fire someone for whatever reason.
There are a few reasons (working with a union being one of them in parts
of the country) where firing someone (or not hiring them) is not
permitted.

Debian generally has fairly protected speech (in my country at least)
when the project chooses to make statements.  That is, there are few
reasons the government can come along and shut Debian's speech down.
There are some though.

Debian (at least in the countries of many participants here) is able to
limit the speech of people within Debian channels like this mailing list
and our conferences, website, and distribution.
There mopey be  some ways in which we could limit speech that might
be problematic in terms of our non-profit status.
There may be some forms of speech we could permit that would be
problematic.
But for the most part we can police our community as we like.

In general many of us prefer to be generally open.
We've decided though that creating an inclusive, welcoming, respectful
community is more important than openness.
That is not a violation of freedom of speech.


signature.asc
Description: PGP signature

Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io

[Sam Hartman]

> "Sruthi" == Sruthi Chandran  writes:

Sruthi> I propose that instead of signing the said letter, Debian
Sruthi> issue a position statement. The text of the statement is
Sruthi> adapted from the statements by FSFE and EFF.

Sruthi>  Text of GR 

Sruthi> Release a position statement with the following text.

Can you please propose as an amendment to Steve's GR rather than as a
separate GR?
I'd rather have two ballot options than two separate votes.

Also, we generally include the constitutional section (4.1.5) under
which we're acting in a GR.
See Sean's message as an example how to do this.

Sruthi> One crucial factor in making our community more inclusive is
Sruthi> to recognise and reflect when other people are offended or
Sruthi> harmed by our own actions and consider this feedback in

Would you be willing to drop the word offended from the above?

I think that focusing on offense rather than harm detracts from the
power of the progressive agenda and of moving for social justice.
It's not about political correctness or a bunch of people running around
with sensitive natures taking offense at whatever they can.
It's about recognizing the pain others are feeling, developing empathy
with them, and working to reduce that pain and foster respect.

Making it about offense gives people who disagree with social justice
work an easy way to trivialize what we're doing.

--Sam


signature.asc
Description: PGP signature

Re: Amendment to rms-open-letter GR

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> The vote to restore Stallman to the board was not unanimous,
Sean> and there is some confusion about how the procedure for
Sean> elections to the board actually works, so the call to remove
Sean> *all* board members does not make sense to me.  And the FSF is
Sean> going to need people with experience to help it recover from
Sean> this whole affair.

I hope that those who didn't vote for rms's return resign because they
cannot ethically stand with the FSF.
That's the context in which I think it is reasonable to call for the
entire board's resignation.