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.</cite></p>
</li>
<li>
[-<p>In case of-]{+<p>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.</p>-]{+this power of+}
{+ the developers is not used.</p>+}
</li>
{+<li>+}
{+ <p>Override a decision of the project secretary or their+}
{+ delegate.</p>+}
{+ <p>Overriding the determination of what super majority is required+}
{+ for a particular ballot option or overriding the determination of+}
{+ the outcome of an election requires the developers to agree by a+}
{+ 3:1 majority. The determination of the majority required to+}
{+ override a decision of the secretary is not subject to+}
{+ override.</p>+}
{+ <p>The chair of the technical committee decides who acts as+}
{+ secretary for a general resolution to override a decision of the+}
{+ project secretary or their delegate. If the decision was not made+}
{+ by the chair of the technical committee, the committee chair may+}
{+ themselves act as secretary. The decision of who acts as secretary+}
{+ for such a general resolution is not subject to override.</p>+}
</ol>
<h3>4.2. Procedure</h3>
@@ -228,9 +246,10 @@ earlier can overrule everyone listed later.</cite></p>
<p>
Votes are taken by the Project Secretary. Votes, tallies, and
results are not revealed during the voting period; after the
vote the Project Secretary lists all the votes {+cast 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.
</p>
</li>
@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.</cite></p>
</li>
<li>
<p>Votes are cast[-by email-] in a manner suitable to the Secretary.
The Secretary determines for each poll whether voters can change
their votes.</p>
</li>
@@ -371,8 +390,7 @@ earlier can overrule everyone listed later.</cite></p>
necessary.</li>
<li>The next two weeks are the polling period during which
Developers may cast their votes. [-Votes in leadership elections are-]
[- kept secret, even after the election is finished.</li>-]{+</li>+}
<li>The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
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.</cite></p>
</li>
[-<p>In case of-]{+<p>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.</p>-]{+this power of+}
{+ the developers is not used.</p>+}
</li>
{+<li>+}
{+ <p>Override a decision of the project secretary or their+}
{+ delegate.</p>+}
{+ <p>Overriding the determination of what super majority is required+}
{+ for a particular ballot option or overriding the determination of+}
{+ the outcome of an election requires the developers to agree by a+}
{+ 3:1 majority. The determination of the majority required to+}
{+ override a decision of the secretary is not subject to+}
{+ override.</p>+}
{+ <p>The chair of the technical committee decides who acts as+}
{+ secretary for a general resolution to override a decision of the+}
{+ project secretary or their delegate. If the decision was not made+}
{+ by the chair of the technical committee, the committee chair may+}
{+ themselves act as secretary. The decision of who acts as secretary+}
{+ for such a general resolution is not subject to override.</p>+}
</ol>
<h3>4.2. Procedure</h3>
@@ -228,9 +246,10 @@ earlier can overrule everyone listed later.</cite></p>
<p>
Votes are taken by the Project Secretary. Votes, tallies, and
results are not revealed during the voting period; after the
vote the Project Secretary lists all the votes {+cast 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.
</p>
</li>
@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.</cite></p>
</li>
<p>Votes are cast[-by email-] in a manner suitable to the Secretary.
The Secretary determines for each poll whether voters can change
their votes.</p>
</li>
@@ -371,8 +390,7 @@ earlier can overrule everyone listed later.</cite></p>
necessary.</li>
<li>The next two weeks are the polling period during which
Developers may cast their votes. [-Votes in leadership elections are-]
[- kept secret, even after the election is finished.</li>-]{+</li>+}
<li>The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
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.</cite></p>
</li>
<li>
[-<p>In case of-]{+<p>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.</p>-]{+this power of+}
{+ the developers is not used.</p>+}
</li>
{+<li>+}
{+ <p>Override a decision of the project secretary or their+}
{+ delegate.</p>+}
{+ <p>Overriding the determination of what super majority is required+}
{+ for a particular ballot option or overriding the determination of+}
{+ the outcome of an election requires the developers to agree by a+}
{+ 3:1 majority. The determination of the majority required to+}
{+ override a decision of the secretary is not subject to+}
{+ override.</p>+}
{+ <p>The chair of the technical committee decides who acts as+}
{+ secretary for a general resolution to override a decision of the+}
{+ project secretary or their delegate. If the decision was not made+}
{+ by the chair of the technical committee, the committee chair may+}
{+ themselves act as secretary. The decision of who acts as secretary+}
{+ for such a general resolution is not subject to override.</p>+}
</ol>
<h3>4.2. Procedure</h3>
@@ -228,9 +246,10 @@ earlier can overrule everyone listed later.</cite></p>
<p>
Votes are taken by the Project Secretary. Votes, tallies, and
results are not revealed during the voting period; after the
vote the Project Secretary lists all the votes {+cast 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.
</p>
</li>
@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.</cite></p>
</li>
<li>
<p>Votes are cast[-by email-] in a manner suitable to the Secretary.
The Secretary determines for each poll whether voters can change
their votes.</p>
</li>
@@ -371,8 +390,7 @@ earlier can overrule everyone listed later.</cite></p>
necessary.</li>
<li>The next two weeks are the polling period during which
Developers may cast their votes. [-Votes in leadership elections are-]
[- kept secret, even after the election is finished.</li>-]{+</li>+}
<li>The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
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.</cite></p>
</li>
<li>
[-<p>In case of-]{+<p>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.</p>-]{+this power of+}
{+ the developers is not used.</p>+}
</li>
{+<li>+}
{+ <p>Override a decision of the project secretary or their+}
{+ delegate.</p>+}
{+ <p>Overriding the determination of what super majority is required+}
{+ for a particular ballot option or overriding the determination of+}
{+ the outcome of an election requires the developers to agree by a+}
{+ 3:1 majority. The determination of the majority required to+}
{+ override a decision of the secretary is not subject to+}
{+ override.</p>+}
{+ <p>The chair of the technical committee decides who acts as+}
{+ secretary for a general resolution to override a decision of the+}
{+ project secretary or their delegate. If the decision was not made+}
{+ by the chair of the technical committee, the committee chair may+}
{+ themselves act as secretary. The decision of who acts as secretary+}
{+ for such a general resolution is not subject to override.</p>+}
</ol>
<h3>4.2. Procedure</h3>
@@ -228,9 +246,10 @@ earlier can overrule everyone listed later.</cite></p>
<p>
Votes are taken by the Project Secretary. Votes, tallies, and
results are not revealed during the voting period; after the
vote the Project Secretary lists all the votes {+cast 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.
</p>
</li>
@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.</cite></p>
</li>
<li>
<p>Votes are cast[-by email-] in a manner suitable to the Secretary.
The Secretary determines for each poll whether voters can change
their votes.</p>
</li>
@@ -371,8 +390,7 @@ earlier can overrule everyone listed later.</cite></p>
necessary.</li>
<li>The next two weeks are the polling period during which
Developers may cast their votes. [-Votes in leadership elections are-]
[- kept secret, even after the election is finished.</li>-]{+</li>+}
<li>The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
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.</cite></p>
</li>
[-<p>In case of-]{+<p>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.</p>-]{+this power of+}
{+ the developers is not used.</p>+}
</li>
{+<li>+}
{+ <p>Override a decision of the project secretary or their+}
{+ delegate.</p>+}
{+ <p>Overriding the determination of what super majority is required+}
{+ for a particular ballot option or overriding the determination of+}
{+ the outcome of an election requires the developers to agree by a+}
{+ 3:1 majority. The determination of the majority required to+}
{+ override a decision of the secretary is not subject to+}
{+ override.</p>+}
{+ <p>The chair of the technical committee decides who acts as+}
{+ secretary for a general resolution to override a decision of the+}
{+ project secretary or their delegate. If the decision was not made+}
{+ by the chair of the technical committee, the committee chair may+}
{+ themselves act as secretary. The decision of who acts as secretary+}
{+ for such a general resolution is not subject to override.</p>+}
</ol>
<h3>4.2. Procedure</h3>
@@ -228,9 +246,10 @@ earlier can overrule everyone listed later.</cite></p>
<p>
Votes are taken by the Project Secretary. Votes, tallies, and
results are not revealed during the voting period; after the
vote the Project Secretary lists all the votes {+cast 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.
</p>
</li>
@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.</cite></p>
</li>
<p>Votes are cast[-by email-] in a manner suitable to the Secretary.
The Secretary determines for each poll whether voters can change
their votes.</p>
</li>
@@ -371,8 +390,7 @@ earlier can overrule everyone listed later.</cite></p>
necessary.</li>
<li>The next two weeks are the polling period during which
Developers may cast their votes. [-Votes in leadership elections are-]
[- kept secret, even after the election is finished.</li>-]{+</li>+}
<li>The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
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.</cite></p>
</li>
<li>
[-<p>In case of-]{+<p>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.</p>-]{+this power of+}
{+ the developers is not used.</p>+}
</li>
{+<li>+}
{+ <p>Override a decision of the project secretary or their+}
{+ delegate.</p>+}
{+ <p>Overriding the determination of what super majority is required+}
{+ for a particular ballot option or overriding the determination of+}
{+ the outcome of an election requires the developers to agree by a+}
{+ 3:1 majority. The determination of the majority required to+}
{+ override a decision of the secretary is not subject to+}
{+ override.</p>+}
{+ <p>The chair of the technical committee decides who acts as+}
{+ secretary for a general resolution to override a decision of the+}
{+ project secretary or their delegate. If the decision was not made+}
{+ by the chair of the technical committee, the committee chair may+}
{+ themselves act as secretary. The decision of who acts as secretary+}
{+ for such a general resolution is not subject to override.</p>+}
</ol>
<h3>4.2. Procedure</h3>
@@ -228,9 +246,10 @@ earlier can overrule everyone listed later.</cite></p>
<p>
Votes are taken by the Project Secretary. Votes, tallies, and
results are not revealed during the voting period; after the
vote the Project Secretary lists all the votes {+cast 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.
</p>
</li>
@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.</cite></p>
</li>
<li>
<p>Votes are cast[-by email-] in a manner suitable to the Secretary.
The Secretary determines for each poll whether voters can change
their votes.</p>
</li>
@@ -371,8 +390,7 @@ earlier can overrule everyone listed later.</cite></p>
necessary.</li>
<li>The next two weeks are the polling period during which
Developers may cast their votes. [-Votes in leadership elections are-]
[- kept secret, even after the election is finished.</li>-]{+</li>+}
<li>The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
"Pierre-Elliott" == Pierre-Elliott Bécue <peb@debian.org> writes:
I propose the following amendment to this ballot option, which if
rejected I propose as its own option:
"Don" == Don Armstrong <don@debian.org> writes:
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.
"Pierre-Elliott" == Pierre-Elliott Bcue <peb@debian.org> 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.
On Fri, Feb 25, 2022 at 08:06:20AM -0700, Sam Hartman wrote:
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 plan to look at least at belenios is voting by email is no longer
required. My plan is to run at least a small test to see if people like
it or not. I could maybe also run a larger poll. But we'll see about
how we pick a different system, or not, later.
I propose the following amendment to this ballot option, which if
rejected I propose as its own option:
modified english/devel/constitution.wml
@@ -266,7 +266,8 @@ earlier can overrule everyone listed later.</cite></p>
</li>
<li>
- <p>Votes are cast in a manner suitable to the Secretary.
+ <p>Votes are cast by email in a manner suitable to the Secretary.
+ Non-email methods suitable to the Secretary may be used in addition to e-mail.
The Secretary determines for each poll whether voters can change
their votes.</p>
</li>
https://salsa.debian.org/don/webwml/-/commit/9bbc20fed6881fa5b239830cad0939b979bbe300
Rationale: e-mail should continue to be an option for casting votes even while alternative methods of casting ballots might 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.
However, I don't think it should take a 3:1 super majority to change
how we collect votes.
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.
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.
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 plan to look at least at belenios is voting by email is no longer
required. My plan is to run at least a small test to see if people
like it or not. I could maybe also run a larger poll. But we'll see
about how we pick a different system, or not, later.
"Don" == Don Armstrong <don@debian.org> writes:
I plan to look at least at belenios is voting by email is no longer
required. My plan is to run at least a small test to see if people
like it or not. I could maybe also run a larger poll. But we'll see
about how we pick a different system, or not, later.
Looks interesting. I know (having hacked up devotee to make
pocket-devotee) that the plumbing around these systems is complicated;
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.
Sean> Could we have a diff, please?"Sean" == Sean Whitton <spwhitton@spwhitton.name> writes:
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.
[[PGP Signed Part:No public key for 2C6C4C3CA8378674 created at 2022-03-03T21:54:36+0100 using EDDSA]]
I hereby amend the ballot option I proposed using the procedure in Constitution section A.1. My understanding is that this amendment
replaces my ballot option unless one of the sponsors objects.
There are two changes. The first is the change to rationale I sent out yesterday. The second is to insert a newline between the General
Resolution title and the following line of '=' characters.
I also believe this advances the end of the discussion period to next Thursday (although other actions may advance the end of the discussion
period further).
----------------------------------------
Rationale
=========
During the vote for GR_2021_002, several developers said they were uncomfortable voting because under the process at that time, their name
and ballot ranking would be public.
A number of participants in the discussion believe that we would get
election results that more accurately reflect the will of the developers
if we do not make the name associated with a particular vote on the
tally sheet public.
Several people believed that the ranked votes without names attached
would still be valuable public information.
This proposal would treat all elections like DPL elections.
At the same time it relaxes the requirement that the secretary must
conduct a vote via email. If the requirement for email voting is
removed, then an experiment is planned at least with the belenios voting system [1]. belenios may provide better voter secrecy and an easier
web-based voting system than our current email approach.
If this proposal passes, adopting such an alternative
would require sufficient support in the project but would not require
another constitutional amendment.
[1]: https://lists.debian.org/YhoTRIxtz3AIpO+g@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.</cite></p>
</li>
<li>
[-<p>In case of-]{+<p>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.</p>-]{+this power of+}
{+ the developers is not used.</p>+}
</li>
{+<li>+}
{+ <p>Override a decision of the project secretary or their+}
{+ delegate.</p>+}
{+ <p>Overriding the determination of what super majority is required+}
{+ for a particular ballot option or overriding the determination of+}
{+ the outcome of an election requires the developers to agree by a+}
{+ 3:1 majority. The determination of the majority required to+}
{+ override a decision of the secretary is not subject to+}
{+ override.</p>+}
{+ <p>The chair of the technical committee decides who acts as+}
{+ secretary for a general resolution to override a decision of the+}
{+ project secretary or their delegate. If the decision was not made+}
{+ by the chair of the technical committee, the committee chair may+}
{+ themselves act as secretary. The decision of who acts as secretary+}
{+ for such a general resolution is not subject to override.</p>+}
</ol>
<h3>4.2. Procedure</h3>
@@ -228,9 +246,10 @@ earlier can overrule everyone listed later.</cite></p>
<p>
Votes are taken by the Project Secretary. Votes, tallies, and
results are not revealed during the voting period; after the
vote the Project Secretary lists all the votes {+cast 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.
</p>
</li>
@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.</cite></p>
</li>
<li>
<p>Votes are cast[-by email-] in a manner suitable to the Secretary.
The Secretary determines for each poll whether voters can change
their votes.</p>
</li>
@@ -371,8 +390,7 @@ earlier can overrule everyone listed later.</cite></p>
necessary.</li>
<li>The next two weeks are the polling period during which
Developers may cast their votes. [-Votes in leadership elections are-]
[- kept secret, even after the election is finished.</li>-]{+</li>+}
<li>The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of The
[[End of PGP Signed Part]]
<li>The next two weeks are the polling period during which
Developers may cast their votes. [-Votes in leadership elections
are-]
[- kept secret, even after the election is finished.</li>-]{+</li>+}
I've been reading our new constitution about the discussion period. What
I find is this in A.1.1:
The discussion period starts when a draft resolution is proposed and sponsored. The minimum discussion period is 2 weeks. The maximum
discussion period is 3 weeks.
And in A.1.4:
The addition of a ballot option or the change via an amendment of a
ballot option changes the end of the discussion period to be one
week from when that action was done [...]
As I see it, there is only a minimum and a maximum, but not some
default. After it's over, the secretary just call for vote. My
interpretation is that as long as the minimum and maximum is not the
same, the secretary can declare that the period is over after the
minimum is over, but can also wait until the maximum is over before
declaring it's over.
So I can actually already say when the voting period is going to be,
and am going for Saturday 2022-03-19 to Friday 2022-04-01, which will
then directly be followed by the DPL vote.
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).
"Ansgar" == Ansgar <ansgar@43-1.org> writes:
So reading A.1.4 again, I can also see it as just saying that it really updates when the period is over. I think it would have just been more
clear if A.1.1 said "The initial discussion period is 2 weeks."
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.
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
+1Why don't you use JavaScript? I also don't like enabling JavaScript inBecause I use lynx as browser.
"Thorsten" == Thorsten Glaser <tg@debian.org> writes:
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.
These days though, modern browsers actually have better
technology for navigating a web page accessibly than Lynx does.
is not directly an accessibility issue. In some cases it is because
misleading to simply say doesn't work with Lynx == accessibility
problem.
regular basis please don't spread the myth that Lynx == accessibility.
Sam Hartman dixit:
Thorsten> Alternative solutions may • have accessibility problems
Thorsten> (not work with lynx, for example
Working with Lynx is not a requirement for accessibility.
No, but not working with lynx is an accessibility problem.
But that’s not the only use case. Slow connections, text only,
or even font sizes (lynx runs in a terminal where *I* choose
that), are other use cases.
Also, JavaScript thingies tend to be over-designed. There was
this firewall solution I encountered at work where you had to
drag-and-drop things to create and order firewall rules.
I’d argue having to rely on proprietary JavaScript drawing things
is both an accessibility and a worse issue (GNU LibreJS seems to
not have gone anywhere, plus, with it enabled you’d have just the
same site breakage as in lynx).
Sam Hartman dixit:
Thorsten> Alternative solutions may • have accessibility problems
Thorsten> (not work with lynx, for example
Working with Lynx is not a requirement for accessibility.
No, but not working with lynx is an accessibility problem.
Obviously accessibility depends on what your requirements are.
Exactly.
The needs of someone who is blind are different than than for someone
who has mobility issues for example.
Right.
I occasionally help out a couple of blind users on the lynx mailing
list. Some of them are on DOS systems and shell out to Unix systems
to access lynx, even.
But that’s not the only use case. Slow connections, text only,
or even font sizes (lynx runs in a terminal where *I* choose
that), are other use cases.
Also, JavaScript thingies tend to be over-designed. There was
this firewall solution I encountered at work where you had to
drag-and-drop things to create and order firewall rules.
The current solution is to just enter a couple of numbers,
sign and send, which is just perfect for many use cases.
Can we at least agree that there are multiple use cases and there
is not a single solution covering all of them out of the box?
IIRC you mention something about writing a frontend to help craft
the mails that are sent to the voting system. I agree that having
the need for that, in such a technology-oriented community that
Debian is, while surprising to me, shows that eMail only has its
problems.
But I want to assert that removing the current, working, method
cannot be a/the solution for that problem either.
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.
Yeah. I use lynx daily and do encounter this problem. I have an
ever-changing mix of browsers to fall back to, but the developers
of Firefox seem to want to make my life just so much harder (ever
since the update from 78 to 91 it’s so slow it’s barely usable on
a Core2Duo laptop), and I really hate the bad mouse-oriented
usability of it. Also, lynx at least has black background in my
terminal…
These days though, modern browsers actually have better
technology for navigating a web page accessibly than Lynx does.
Again, depends on your use case. In my case, the font and colour
selection being user-controlled, the blazing-fast rendering (also
on page down, search, etc.), links and form fields are numbered,
textfields need activation, and the space and b keys for scrolling
is massively superiour to any graphical browser (even though links2
comes somewhat close… I like it as manga viewer, but it has issues elsewhere).
is not directly an accessibility issue. In some cases it is because
I’d argue having to rely on proprietary JavaScript drawing things
is both an accessibility and a worse issue (GNU LibreJS seems to
not have gone anywhere, plus, with it enabled you’d have just the
same site breakage as in lynx).
Webbrowsing at the German ministry for IT security also is (or at
least was $smallnum years ago) enforcing JS disabled for GUI browsers.
misleading to simply say doesn't work with Lynx == accessibility
problem.
I will continue to assert that it is, even if not for the obvious
reasons it used to be, with the reasons I listed above.
regular basis please don't spread the myth that Lynx == accessibility.
I’m not. I *do* spread that !Lynx == !accessibility though, which
I have enough reasons to consider justified.
(There’s also the ROCA principle, in which some webpage should
work fine without CSS and JS, and every “layer” (CSS, then JS)
added just makes it “nicer”. I attended a tech talk by someone
proposing this and figured that it’s also a great case for both
lynx and some amount of a11y out of the box. I think the other
attendees were a bit… surprised by the presenter and me nerding
about it like that… but it’s a point.)
Sorry for rambling, it’s late and I need sleep. I hope I was
at least able to make my points.
Goodnight,
//mirabilos
Please, a Debian developer who uses a screen reader is saying that
"works with lynx is not required to be accessible to people with >disabilities". Saying you're talking about accessibility, but then
Wish I had pine to hand :-( I'll give lynx a try, thanks.
Sam Hartman dixit:
Thorsten> Alternative solutions may • have accessibility problems
Thorsten> (not work with lynx, for example
Working with Lynx is not a requirement for accessibility.
No, but not working with lynx is an accessibility problem.
Obviously accessibility depends on what your requirements are.
Exactly.
The needs of someone who is blind are different than than for someone
who has mobility issues for example.
Right.
I occasionally help out a couple of blind users on the lynx mailing
list. Some of them are on DOS systems and shell out to Unix systems
to access lynx, even.
But that’s not the only use case. Slow connections, text only,
or even font sizes (lynx runs in a terminal where *I* choose
that), are other use cases.
Also, JavaScript thingies tend to be over-designed. There was
this firewall solution I encountered at work where you had to
drag-and-drop things to create and order firewall rules.
The current solution is to just enter a couple of numbers,
sign and send, which is just perfect for many use cases.
Can we at least agree that there are multiple use cases and there
is not a single solution covering all of them out of the box?
IIRC you mention something about writing a frontend to help craft
the mails that are sent to the voting system. I agree that having
the need for that, in such a technology-oriented community that
Debian is, while surprising to me, shows that eMail only has its
problems.
But I want to assert that removing the current, working, method
cannot be a/the solution for that problem either.
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.
Yeah. I use lynx daily and do encounter this problem. I have an
ever-changing mix of browsers to fall back to, but the developers
of Firefox seem to want to make my life just so much harder (ever
since the update from 78 to 91 it’s so slow it’s barely usable on
a Core2Duo laptop), and I really hate the bad mouse-oriented
usability of it. Also, lynx at least has black background in my
terminal…
These days though, modern browsers actually have better
technology for navigating a web page accessibly than Lynx does.
Again, depends on your use case. In my case, the font and colour
selection being user-controlled, the blazing-fast rendering (also
on page down, search, etc.), links and form fields are numbered,
textfields need activation, and the space and b keys for scrolling
is massively superiour to any graphical browser (even though links2
comes somewhat close… I like it as manga viewer, but it has issues elsewhere).
is not directly an accessibility issue. In some cases it is because
I’d argue having to rely on proprietary JavaScript drawing things
is both an accessibility and a worse issue (GNU LibreJS seems to
not have gone anywhere, plus, with it enabled you’d have just the
same site breakage as in lynx).
Webbrowsing at the German ministry for IT security also is (or at
least was $smallnum years ago) enforcing JS disabled for GUI browsers.
misleading to simply say doesn't work with Lynx == accessibility
problem.
I will continue to assert that it is, even if not for the obvious
reasons it used to be, with the reasons I listed above.
regular basis please don't spread the myth that Lynx == accessibility.
I’m not. I *do* spread that !Lynx == !accessibility though, which
I have enough reasons to consider justified.
(There’s also the ROCA principle, in which some webpage should
work fine without CSS and JS, and every “layer” (CSS, then JS)
added just makes it “nicer”. I attended a tech talk by someone
proposing this and figured that it’s also a great case for both
lynx and some amount of a11y out of the box. I think the other
attendees were a bit… surprised by the presenter and me nerding
about it like that… but it’s a point.)
Sorry for rambling, it’s late and I need sleep. I hope I was
at least able to make my points.
Goodnight,
//mirabilos
--
"Using Lynx is like wearing a really good pair of shades: cuts out
the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
-- Henry Nelson, March 1999
<div>While text *is* usually accessible, it's not always the easiest to use. Take email for example. Having quoted material at the top of the message means that I (using the Gmail web app), must arrow through possibly many levels of quotedmaterial to get to the reply, and since I may have just heard the material that is now quoted just moments before, it's not all that useful right now as I reread it. However, I'm not going to ask that this way of producing email be changed;
I use many different operating systems, as a person who is blind. I don't […]
While text *is* usually accessible, it's not always the easiest to use.
Devin Prater dixit:
I use many different operating systems, as a person who is blind. I don't[…]
While text *is* usually accessible, it's not always the easiest to use.
My point here was that there are *other* cases where lack of
lynx support means lack of accessibility, even if this seems
to no longer be true for *some* (perhaps even most? there IS
a steady stream of people on the lynx mailing list…) vision‐
impaired users there are other usecases.
bye,
//mirabilos
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
This is a very bad idea.
Alternative solutions may
• have accessibility problems (not work with lynx, for example)
• require different transport (eMail can be done in batches)
• be tricky to do with PGP signatures (and substituting web-ish
logins has its own kind of trouble (not least with lynx compat))
• require more on the system, especially if it does not work with
lynx (such as heavy-weight UI with JS-capable browsers)
• be more easy to filter (think countries’ web firewall) than eMail
• have age requirements (many web services exclude minors for no
good reason)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 41:01:07 |
| Calls: | 6,708 |
| Calls today: | 1 |
| Files: | 12,243 |
| Messages: | 5,353,786 |