I propose the following General Resolution, which will require a 3:1 >majority, and am seeking sponsors.
Rationale
=========
We have uncovered several problems with the current constitutional
mechanism for preparing a Technical Committee resolution or General >Resolution for vote:
* The timing of calling for a vote is discretionary and could be used
strategically to cut off discussion while others were preparing
additional ballot options.
* The original proposer of a GR has special control over the timing of the
vote, which could be used strategically to the disadvantage of other
ballot options.
* The description of the process for adding and managing additional ballot
options is difficult to understand.
* The current default choice of "further discussion" for a General
Resolution has implications beyond rejecting the other options that may,
contrary to its intent, discourage people Developers ranking it above
options they wish to reject.
The actual or potential implications of these problems caused conflict in
the Technical Committee systemd vote and in GRs 2019-002 and 2021-002,
which made it harder for the project to reach a fair and widely-respected >result.
This constitutional change attempts to address those issues by
* separating the Technical Committee process from the General Resolution
process since they have different needs;
* requiring (passive) consensus among TC members that a resolution is
ready to proceed to a vote;
* setting a maximum discussion period for a TC resolution and then
triggering a vote;
* setting a maximum discussion period for a GR so that the timing of the
vote is predictable;
* extending the GR discussion period automatically if the ballot changes;
* modifying the GR process to treat all ballot options equally, with a
clearer process for addition, withdrawal, and amendment;
* changing the default option for a GR to "none of the above"; and
* clarifying the discretion extended to the Project Secretary.
It also corrects a technical flaw that left the outcome of the vote for >Technical Committee Chair undefined in the event of a tie, and clarifies >responsibilities should the Technical Committee put forward a General >Resolution under point 4.2.1.
Effect of the General Resolution
================================
The Debian Developers, by way of General Resolution, amend the Debian >constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Section 4.2.4
-------------
Strike the sentence "The minimum discussion period is 2 weeks, but may be >varied by up to 1 week by the Project Leader." (A modified version of
this provision is added to section A below.) Add to the end of this
point:
The default option is "None of the above."
Section 4.2.5
-------------
Replace "amendments" with "ballot options."
Section 5.1.5
-------------
Replace in its entirety with:
Propose General Resolutions and ballot options for General
Resolutions. When proposed by the Project Leader, sponsors for the
General Resolution or ballot option are not required; see §4.2.1.
Section 5.2.7
-------------
Replace "section §A.6" with "section §A.5".
Section 6.1.7
-------------
Replace "section §A.6" with "section §A.5".
Add to the end of this point:
There is no casting vote. If there are multiple options with no
defeats in the Schwartz set at the end of A.5.8, the winner will be
randomly chosen from those options, via a mechanism chosen by the
Project Secretary.
Section 6.3
-----------
Replace 6.3.1 in its entirety with:
1. Resolution process.
The Technical Committee uses the following process to prepare a
resolution for vote:
1. Any member of the Technical Committee may propose a resolution.
This creates an initial two-option ballot, the other option
being the default option of "Further discussion." The proposer
of the resolution becomes the proposer of the ballot option.
2. Any member of the Technical Committee may propose additional
ballot options or modify or withdraw a ballot option they
proposed.
3. If all ballot options except the default option are withdrawn,
the process is canceled.
4. Any member of the Technical Committee may call for a vote on the
ballot as it currently stands. This vote begins immediately, but
if any other member of the Technical Committee objects to
calling for a vote before the vote completes, the vote is
canceled and has no effect.
5. Two weeks after the original proposal the ballot is closed to
any changes and voting starts automatically. This vote cannot be
canceled.
6. If a vote is canceled under point 6.3.1.4 later than 13 days
after the initial proposed resolution, the vote specified in
point 6.3.1.5 instead starts 24 hours after the time of
cancellation. During that 24 hour period, no one may call for a
vote.
Add a new paragraph to the start of 6.3.2 following "Details regarding >voting":
Votes are decided by the vote counting mechanism described in
section §A.5. The voting period lasts for one week or until the
outcome is no longer in doubt assuming no members change their
votes, whichever is shorter. Members may change their votes until
the voting period ends. There is a quorum of two. The Chair has a
casting vote. The default option is "Further discussion."
Strike "The Chair has a casting vote." from the existing text and make the >remaining text a separate, second paragraph.
In 6.3.3, replace "amendments" with "ballot options."
Add, at the end of section 6.3, the following new point:
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.
Section A
---------
Replace A.0 through A.4 in their entirety with:
A.0. Proposal
1. The formal procedure begins when a draft resolution is proposed and
sponsored, as required. A draft resolution must include the text of
that resolution and a short single-line summary suitable for
labeling the ballot choice.
2. This draft resolution becomes a ballot option in an initial
two-option ballot, the other option being the default option, and
the proposer of the draft resolution becomes the proposer of that
ballot option.
A.1. Discussion and amendment
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.
2. A new ballot option may be proposed and sponsored according to the
requirements for a new resolution.
3. The proposer of a ballot option may amend that option provided that
none of the sponsors of that ballot option at the time the
amendment is proposed disagree with that change within 24 hours. If
any of them do disagree, the ballot option is left unchanged.
4. The addition of a ballot option or the change via a amendment of a
ballot option changes the end of the discussion period to be one
week from when that action was done, unless that would make the
total discussion period shorter than the minimum discussion period
or longer than the maximum discussion period. In the latter case,
the length of the discussion period is instead set to the maximum
discussion period.
5. The proposer of a ballot option may make minor changes to that
option (for example, typographical fixes, corrections of
inconsistencies, or other changes which do not alter the meaning),
providing no Developer objects within 24 hours. In this case the
length of the discussion period is not changed. If a Developer does
object, the change must instead be made via amendment under point
A.1.3.
6. The Project Leader may, at any point in the process, increase or
decrease the minimum and maximum discussion period by up to 1 week
from their original values in point A.1.1, except that they may not
do so in a way that causes the discussion period to end within 48
hours of when this change is made. The length of the discussion
period is then recalculated as if the new minimum and maximum
lengths had been in place during all previous ballot changes under
points A.1.1 and A.1.4.
7. The default option has no proposer or sponsors, and cannot be
amended or withdrawn.
A.2. Withdrawing ballot options
1. The proposer of a ballot option may withdraw. If they do, new
proposers may come forward to keep the ballot option alive, in
which case the first person to do so becomes the new proposer and
any others become sponsors if they aren't sponsors already. Any new
proposer or sponsors must meet the requirements for proposing or
sponsoring a new resolution.
2. A sponsor of a ballot option may withdraw.
3. If the withdrawal of the proposer and/or sponsors means that a
ballot option has no proposer or not enough sponsors to meet the
requirements for a new resolution, and 24 hours pass without this
being remedied by another proposer and/or sponsors stepping
forward, it removed from the draft ballot. This does not change
the length of the discussion period.
4. If all ballot options except the default option are withdrawn, the
resolution is canceled and will not be voted on.
A.3. Calling for a vote
1. After the discussion period has ended, the Project Secretary will
publish the ballot and call for a vote. The Project Secretary may
do this immediately following the end of the discussion period and
must do so within five days of the end of the discussion period.
2. The Project Secretary determines the order of ballot options. At
their discretion they may reword the single-line summaries for
clarity.
3. Minor changes to ballot options under point A.1.5 may not be made
after or within 24 hours of the end of the discussion period unless
the Project Secretary agrees the change does not alter the meaning
of the ballot option and (if it would do so) warrants delaying the
vote. The Project Secretary will allow 24 hours for objections
after any such change before issuing the call for a vote.
4. No new ballot options may be proposed, no ballot options may be
amended, and no proposers or sponsors may withdraw within 24 hours
of the end of the discussion period unless this action successfully
extends the discussion period under point A.1.4 by at least 24
additional hours.
5. Actions to preserve the existing ballot may be taken within 24
hours of the end of the discussion period, namely a sponsor
objecting to an amendment under point A.1.3, a Developer objecting
to a minor change under point A.1.5, stepping forward as the
proposer for an existing ballot option whose original proposer has
withdrawn it under point A.2.1, or sponsoring an existing ballot
option that has fewer than the required number of sponsors because
of the withdrawal of a sponsor under point A.2.2.
6. The Project Secretary may make an exception to point A.3.4 and
accept changes to the ballot after they are no longer allowed,
provided that this is done at least 24 hours prior to the issuance
of a call for a vote. All other requirements for making a change to
the ballot must still be met. This is expected to be rare and
should only be done if the Project Secretary believes it would be
harmful to the best interests of the project for the change to not
be made.
A.4. Voting procedure
1. Options which do not have an explicit supermajority requirement
have a 1:1 majority requirement. The default option does not have
any supermajority requirements.
2. The votes are counted according to the rules in section §A.5.
3. In cases of doubt the Project Secretary shall decide on matters of
procedure.
Strike section A.5 in its entirety.
Rename section A.6 to A.5.
Replace the paragraph at the end of section A.6 (now A.5) with:
When the vote counting mechanism of the Standard Resolution Procedure
is to be used, the text which refers to it must specify who has a
casting vote, the quorum, the default option, and any supermajority
requirement. The default option must not have any supermajority
requirements.
Although, I think you should fix A.2.3 which currently says:
... sponsors stepping forward, it removed from the draft ballot.^
which I'd suggest needs an 'is', or perhaps 'will be', between 'it' & 'removed'
This constitutional change attempts to address those issues by
* separating the Technical Committee process from the General Resolution
process since they have different needs;
* requiring (passive) consensus among TC members that a resolution is
ready to proceed to a vote;
* setting a maximum discussion period for a TC resolution and then
triggering a vote;
* setting a maximum discussion period for a GR so that the timing of the
vote is predictable;
* extending the GR discussion period automatically if the ballot changes;
* modifying the GR process to treat all ballot options equally, with a
clearer process for addition, withdrawal, and amendment;
* changing the default option for a GR to "none of the above"; and
* clarifying the discretion extended to the Project Secretary.
... sponsors stepping forward, it removed from the draft ballot.^
"Russ" == Russ Allbery <rra@debian.org> writes:
[[PGP Signed Part:No public key for 7D80315C5736DE75 created at 2021-11-20T19:04:07+0100 using RSA]]
I propose the following General Resolution, which will require a 3:1 majority, and am seeking sponsors.
Rationale
=========
We have uncovered several problems with the current constitutional
mechanism for preparing a Technical Committee resolution or General Resolution for vote:
* The timing of calling for a vote is discretionary and could be used
strategically to cut off discussion while others were preparing
additional ballot options.
* The original proposer of a GR has special control over the timing of the
vote, which could be used strategically to the disadvantage of other
ballot options.
* The description of the process for adding and managing additional ballot
options is difficult to understand.
* The current default choice of "further discussion" for a General
Resolution has implications beyond rejecting the other options that may,
contrary to its intent, discourage people Developers ranking it above
options they wish to reject.
The actual or potential implications of these problems caused conflict in
the Technical Committee systemd vote and in GRs 2019-002 and 2021-002,
which made it harder for the project to reach a fair and widely-respected result.
This constitutional change attempts to address those issues by
* separating the Technical Committee process from the General Resolution
process since they have different needs;
* requiring (passive) consensus among TC members that a resolution is
ready to proceed to a vote;
* setting a maximum discussion period for a TC resolution and then
triggering a vote;
* setting a maximum discussion period for a GR so that the timing of the
vote is predictable;
* extending the GR discussion period automatically if the ballot changes;
* modifying the GR process to treat all ballot options equally, with a
clearer process for addition, withdrawal, and amendment;
* changing the default option for a GR to "none of the above"; and
* clarifying the discretion extended to the Project Secretary.
It also corrects a technical flaw that left the outcome of the vote for Technical Committee Chair undefined in the event of a tie, and clarifies responsibilities should the Technical Committee put forward a General Resolution under point 4.2.1.
Effect of the General Resolution
================================
The Debian Developers, by way of General Resolution, amend the Debian constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Section 4.2.4
-------------
Strike the sentence "The minimum discussion period is 2 weeks, but may be varied by up to 1 week by the Project Leader." (A modified version of
this provision is added to section A below.) Add to the end of this
point:
The default option is "None of the above."
Section 4.2.5
-------------
Replace "amendments" with "ballot options."
Section 5.1.5
-------------
Replace in its entirety with:
Propose General Resolutions and ballot options for General
Resolutions. When proposed by the Project Leader, sponsors for the
General Resolution or ballot option are not required; see §4.2.1.
Section 5.2.7
-------------
Replace "section §A.6" with "section §A.5".
Section 6.1.7
-------------
Replace "section §A.6" with "section §A.5".
Add to the end of this point:
There is no casting vote. If there are multiple options with no
defeats in the Schwartz set at the end of A.5.8, the winner will be
randomly chosen from those options, via a mechanism chosen by the
Project Secretary.
Section 6.3
-----------
Replace 6.3.1 in its entirety with:
1. Resolution process.
The Technical Committee uses the following process to prepare a
resolution for vote:
1. Any member of the Technical Committee may propose a resolution.
This creates an initial two-option ballot, the other option
being the default option of "Further discussion." The proposer
of the resolution becomes the proposer of the ballot option.
2. Any member of the Technical Committee may propose additional
ballot options or modify or withdraw a ballot option they
proposed.
3. If all ballot options except the default option are withdrawn,
the process is canceled.
4. Any member of the Technical Committee may call for a vote on the
ballot as it currently stands. This vote begins immediately, but
if any other member of the Technical Committee objects to
calling for a vote before the vote completes, the vote is
canceled and has no effect.
5. Two weeks after the original proposal the ballot is closed to
any changes and voting starts automatically. This vote cannot be
canceled.
6. If a vote is canceled under point 6.3.1.4 later than 13 days
after the initial proposed resolution, the vote specified in
point 6.3.1.5 instead starts 24 hours after the time of
cancellation. During that 24 hour period, no one may call for a
vote.
Add a new paragraph to the start of 6.3.2 following "Details regarding voting":
Votes are decided by the vote counting mechanism described in
section §A.5. The voting period lasts for one week or until the
outcome is no longer in doubt assuming no members change their
votes, whichever is shorter. Members may change their votes until
the voting period ends. There is a quorum of two. The Chair has a
casting vote. The default option is "Further discussion."
Strike "The Chair has a casting vote." from the existing text and make the remaining text a separate, second paragraph.
In 6.3.3, replace "amendments" with "ballot options."
Add, at the end of section 6.3, the following new point:
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.
Section A
---------
Replace A.0 through A.4 in their entirety with:
A.0. Proposal
1. The formal procedure begins when a draft resolution is proposed and
sponsored, as required. A draft resolution must include the text of
that resolution and a short single-line summary suitable for
labeling the ballot choice.
2. This draft resolution becomes a ballot option in an initial
two-option ballot, the other option being the default option, and
the proposer of the draft resolution becomes the proposer of that
ballot option.
A.1. Discussion and amendment
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.
2. A new ballot option may be proposed and sponsored according to the
requirements for a new resolution.
3. The proposer of a ballot option may amend that option provided that
none of the sponsors of that ballot option at the time the
amendment is proposed disagree with that change within 24 hours. If
any of them do disagree, the ballot option is left unchanged.
4. The addition of a ballot option or the change via a amendment of a
ballot option changes the end of the discussion period to be one
week from when that action was done, unless that would make the
total discussion period shorter than the minimum discussion period
or longer than the maximum discussion period. In the latter case,
the length of the discussion period is instead set to the maximum
discussion period.
5. The proposer of a ballot option may make minor changes to that
option (for example, typographical fixes, corrections of
inconsistencies, or other changes which do not alter the meaning),
providing no Developer objects within 24 hours. In this case the
length of the discussion period is not changed. If a Developer does
object, the change must instead be made via amendment under point
A.1.3.
6. The Project Leader may, at any point in the process, increase or
decrease the minimum and maximum discussion period by up to 1 week
from their original values in point A.1.1, except that they may not
do so in a way that causes the discussion period to end within 48
hours of when this change is made. The length of the discussion
period is then recalculated as if the new minimum and maximum
lengths had been in place during all previous ballot changes under
points A.1.1 and A.1.4.
7. The default option has no proposer or sponsors, and cannot be
amended or withdrawn.
A.2. Withdrawing ballot options
1. The proposer of a ballot option may withdraw. If they do, new
proposers may come forward to keep the ballot option alive, in
which case the first person to do so becomes the new proposer and
any others become sponsors if they aren't sponsors already. Any new
proposer or sponsors must meet the requirements for proposing or
sponsoring a new resolution.
2. A sponsor of a ballot option may withdraw.
3. If the withdrawal of the proposer and/or sponsors means that a
ballot option has no proposer or not enough sponsors to meet the
requirements for a new resolution, and 24 hours pass without this
being remedied by another proposer and/or sponsors stepping
forward, it removed from the draft ballot. This does not change
the length of the discussion period.
4. If all ballot options except the default option are withdrawn, the
resolution is canceled and will not be voted on.
A.3. Calling for a vote
1. After the discussion period has ended, the Project Secretary will
publish the ballot and call for a vote. The Project Secretary may
do this immediately following the end of the discussion period and
must do so within five days of the end of the discussion period.
2. The Project Secretary determines the order of ballot options. At
their discretion they may reword the single-line summaries for
clarity.
3. Minor changes to ballot options under point A.1.5 may not be made
after or within 24 hours of the end of the discussion period unless
the Project Secretary agrees the change does not alter the meaning
of the ballot option and (if it would do so) warrants delaying the
vote. The Project Secretary will allow 24 hours for objections
after any such change before issuing the call for a vote.
4. No new ballot options may be proposed, no ballot options may be
amended, and no proposers or sponsors may withdraw within 24 hours
of the end of the discussion period unless this action successfully
extends the discussion period under point A.1.4 by at least 24
additional hours.
5. Actions to preserve the existing ballot may be taken within 24
hours of the end of the discussion period, namely a sponsor
objecting to an amendment under point A.1.3, a Developer objecting
to a minor change under point A.1.5, stepping forward as the
proposer for an existing ballot option whose original proposer has
withdrawn it under point A.2.1, or sponsoring an existing ballot
option that has fewer than the required number of sponsors because
of the withdrawal of a sponsor under point A.2.2.
6. The Project Secretary may make an exception to point A.3.4 and
accept changes to the ballot after they are no longer allowed,
provided that this is done at least 24 hours prior to the issuance
of a call for a vote. All other requirements for making a change to
the ballot must still be met. This is expected to be rare and
should only be done if the Project Secretary believes it would be
harmful to the best interests of the project for the change to not
be made.
A.4. Voting procedure
1. Options which do not have an explicit supermajority requirement
have a 1:1 majority requirement. The default option does not have
any supermajority requirements.
2. The votes are counted according to the rules in section §A.5.
3. In cases of doubt the Project Secretary shall decide on matters of
procedure.
Strike section A.5 in its entirety.
Rename section A.6 to A.5.
Replace the paragraph at the end of section A.6 (now A.5) with:
When the vote counting mechanism of the Standard Resolution Procedure
is to be used, the text which refers to it must specify who has a
casting vote, the quorum, the default option, and any supermajority
requirement. The default option must not have any supermajority
requirements.
1. Any member of the Technical Committee may propose a resolution.
This creates an initial two-option ballot, the other option
being the default option of "Further discussion." The proposer
of the resolution becomes the proposer of the ballot option.
Add a new paragraph to the start of 6.3.2 following "Details regarding voting":
Votes are decided by the vote counting mechanism described in
section §A.5. The voting period lasts for one week or until the
outcome is no longer in doubt assuming no members change their
votes, whichever is shorter. Members may change their votes until
the voting period ends. There is a quorum of two. The Chair has a
casting vote. The default option is "Further discussion."
Strike "The Chair has a casting vote." from the existing text and make the remaining text a separate, second paragraph.
On Sat, 20 Nov 2021, Russ Allbery wrote:
1. Any member of the Technical Committee may propose a resolution.
This creates an initial two-option ballot, the other option
being the default option of "Further discussion." The proposer
of the resolution becomes the proposer of the ballot option.
Suggest making this "None of the above" instead of "Further discussion"
to avoid two different default options for TC decisions vs project
decisions.
Strike "The Chair has a casting vote." from the existing text and make
the remaining text a separate, second paragraph.
I'm assuming the intention is to remove the duplication of "The Chair
has a casting vote", right? [That's what I understood, but textual descriptions of text edits are challenging.]
Because of this (and others), can I suggest that the ballot option be specified as a wdiff to the existing constitution?
Effect of the General Resolution
================================
The Debian Developers, by way of General Resolution, amend the Debian constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Section 4.2.4
-------------
Strike the sentence "The minimum discussion period is 2 weeks, but may be varied by up to 1 week by the Project Leader." (A modified version of
this provision is added to section A below.) Add to the end of this
point:
The default option is "None of the above."
Section 4.2.5
-------------
Replace "amendments" with "ballot options."
Section 5.1.5
-------------
Replace in its entirety with:
Propose General Resolutions and ballot options for General
Resolutions. When proposed by the Project Leader, sponsors for the
General Resolution or ballot option are not required; see §4.2.1.
Section 5.2.7
-------------
Replace "section §A.6" with "section §A.5".
Section 6.1.7
-------------
Replace "section §A.6" with "section §A.5".
Add to the end of this point:
There is no casting vote. If there are multiple options with no
defeats in the Schwartz set at the end of A.5.8, the winner will be
randomly chosen from those options, via a mechanism chosen by the
Project Secretary.
Section 6.3
-----------
Replace 6.3.1 in its entirety with:
1. Resolution process.
The Technical Committee uses the following process to prepare a
resolution for vote:
1. Any member of the Technical Committee may propose a resolution.
This creates an initial two-option ballot, the other option
being the default option of "Further discussion." The proposer
of the resolution becomes the proposer of the ballot option.
2. Any member of the Technical Committee may propose additional
ballot options or modify or withdraw a ballot option they
proposed.
3. If all ballot options except the default option are withdrawn,
the process is canceled.
4. Any member of the Technical Committee may call for a vote on the
ballot as it currently stands. This vote begins immediately, but
if any other member of the Technical Committee objects to
calling for a vote before the vote completes, the vote is
canceled and has no effect.
5. Two weeks after the original proposal the ballot is closed to
any changes and voting starts automatically. This vote cannot be
canceled.
6. If a vote is canceled under point 6.3.1.4 later than 13 days
after the initial proposed resolution, the vote specified in
point 6.3.1.5 instead starts 24 hours after the time of
cancellation. During that 24 hour period, no one may call for a
vote.
Add a new paragraph to the start of 6.3.2 following "Details regarding voting":
Votes are decided by the vote counting mechanism described in
section §A.5. The voting period lasts for one week or until the
outcome is no longer in doubt assuming no members change their
votes, whichever is shorter. Members may change their votes until
the voting period ends. There is a quorum of two. The Chair has a
casting vote. The default option is "Further discussion."
Strike "The Chair has a casting vote." from the existing text and make the remaining text a separate, second paragraph.
In 6.3.3, replace "amendments" with "ballot options."
Add, at the end of section 6.3, the following new point:
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.
Section A
---------
Replace A.0 through A.4 in their entirety with:
A.0. Proposal
1. The formal procedure begins when a draft resolution is proposed and
sponsored, as required. A draft resolution must include the text of
that resolution and a short single-line summary suitable for
labeling the ballot choice.
2. This draft resolution becomes a ballot option in an initial
two-option ballot, the other option being the default option, and
the proposer of the draft resolution becomes the proposer of that
ballot option.
A.1. Discussion and amendment
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.
2. A new ballot option may be proposed and sponsored according to the
requirements for a new resolution.
3. The proposer of a ballot option may amend that option provided that
none of the sponsors of that ballot option at the time the
amendment is proposed disagree with that change within 24 hours. If
any of them do disagree, the ballot option is left unchanged.
4. The addition of a ballot option or the change via a amendment of a
ballot option changes the end of the discussion period to be one
week from when that action was done, unless that would make the
total discussion period shorter than the minimum discussion period
or longer than the maximum discussion period. In the latter case,
the length of the discussion period is instead set to the maximum
discussion period.
5. The proposer of a ballot option may make minor changes to that
option (for example, typographical fixes, corrections of
inconsistencies, or other changes which do not alter the meaning),
providing no Developer objects within 24 hours. In this case the
length of the discussion period is not changed. If a Developer does
object, the change must instead be made via amendment under point
A.1.3.
6. The Project Leader may, at any point in the process, increase or
decrease the minimum and maximum discussion period by up to 1 week
from their original values in point A.1.1, except that they may not
do so in a way that causes the discussion period to end within 48
hours of when this change is made. The length of the discussion
period is then recalculated as if the new minimum and maximum
lengths had been in place during all previous ballot changes under
points A.1.1 and A.1.4.
7. The default option has no proposer or sponsors, and cannot be
amended or withdrawn.
A.2. Withdrawing ballot options
1. The proposer of a ballot option may withdraw. If they do, new
proposers may come forward to keep the ballot option alive, in
which case the first person to do so becomes the new proposer and
any others become sponsors if they aren't sponsors already. Any new
proposer or sponsors must meet the requirements for proposing or
sponsoring a new resolution.
2. A sponsor of a ballot option may withdraw.
3. If the withdrawal of the proposer and/or sponsors means that a
ballot option has no proposer or not enough sponsors to meet the
requirements for a new resolution, and 24 hours pass without this
being remedied by another proposer and/or sponsors stepping
forward, it removed from the draft ballot. This does not change
the length of the discussion period.
4. If all ballot options except the default option are withdrawn, the
resolution is canceled and will not be voted on.
A.3. Calling for a vote
1. After the discussion period has ended, the Project Secretary will
publish the ballot and call for a vote. The Project Secretary may
do this immediately following the end of the discussion period and
must do so within five days of the end of the discussion period.
2. The Project Secretary determines the order of ballot options. At
their discretion they may reword the single-line summaries for
clarity.
3. Minor changes to ballot options under point A.1.5 may not be made
after or within 24 hours of the end of the discussion period unless
the Project Secretary agrees the change does not alter the meaning
of the ballot option and (if it would do so) warrants delaying the
vote. The Project Secretary will allow 24 hours for objections
after any such change before issuing the call for a vote.
4. No new ballot options may be proposed, no ballot options may be
amended, and no proposers or sponsors may withdraw within 24 hours
of the end of the discussion period unless this action successfully
extends the discussion period under point A.1.4 by at least 24
additional hours.
5. Actions to preserve the existing ballot may be taken within 24
hours of the end of the discussion period, namely a sponsor
objecting to an amendment under point A.1.3, a Developer objecting
to a minor change under point A.1.5, stepping forward as the
proposer for an existing ballot option whose original proposer has
withdrawn it under point A.2.1, or sponsoring an existing ballot
option that has fewer than the required number of sponsors because
of the withdrawal of a sponsor under point A.2.2.
6. The Project Secretary may make an exception to point A.3.4 and
accept changes to the ballot after they are no longer allowed,
provided that this is done at least 24 hours prior to the issuance
of a call for a vote. All other requirements for making a change to
the ballot must still be met. This is expected to be rare and
should only be done if the Project Secretary believes it would be
harmful to the best interests of the project for the change to not
be made.
A.4. Voting procedure
1. Options which do not have an explicit supermajority requirement
have a 1:1 majority requirement. The default option does not have
any supermajority requirements.
2. The votes are counted according to the rules in section §A.5.
3. In cases of doubt the Project Secretary shall decide on matters of
procedure.
Strike section A.5 in its entirety.
Rename section A.6 to A.5.
Replace the paragraph at the end of section A.6 (now A.5) with:
When the vote counting mechanism of the Standard Resolution Procedure
is to be used, the text which refers to it must specify who has a
casting vote, the quorum, the default option, and any supermajority
requirement. The default option must not have any supermajority
requirements.
Is there a Git repository somewhere with the canonical copy of the constitution that I an start from? I assume it's somewhere in the www.debian.org machinery, which is something I've never worked with before and am not sure how to get at.
Text of the GR
==============
The Debian Developers, by way of General Resolution, amend the Debian constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Sections 4 through 7
--------------------
Same changes as in Russ' proposal
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Strike the sentence "The maximum discussion period is 3 weeks".
A.1.4. Strike in its entirety
A.1.5. Rename to A.1.4.
A.1.6. Strike in its entirety
A.1.7. Rename to A.1.5.
After A.2, insert:
A.3. Extending the discussion time.
1. When less than 48 hours remain in the discussion time, any Developer
may propose an extension to the discussion time, subject to the
limitations of §A.3.3. These extensions may be seconded according to
the same rules that apply to new ballot options.
2. As soon as a time extension has received the required number of
seconds, these seconds are locked in and cannot be withdrawn, and the
time extension is active.
3. When a time extension has received the required number of seconds,
its proposers and seconders may no longer propose or second any
further time extension for the same ballot, and any further seconds
for the same extension proposal will be ignored for the purpose of
this paragraph. In case of doubt, the Project Secretary decides how
the order of seconds is determined.
4. The first two successful time extensions will extend the discussion
time by one week; any further time extensions will extend the
discussion time by 72 hours.
5. Once the discussion time is longer than 4 weeks, any Developer may
object to further time extensions. Developers who have previously
proposed or seconded a time extension may object as well. If the
number of objections outweigh the proposer and their seconders,
including seconders who will be ignored as per §A.3.3, the time
extension will not be active and the discussion time does not change.
A.3. Rename to A.4.
A.4. Rename to A.5.
A.5. Rename (back) to A.6.
[[PGP Signed Part:No public key for 2DFC519954181296 created at 2021-11-22T16:15:27+0100 using RSA]]
I propose the following amendment. I expect Russ to not accept it, and
am looking for seconds.
Rationale
=========
Much of the rationale of Russ' proposal still applies, and indeed this amendment builds on it. However, the way the timing works is different,
on purpose.
Our voting system, which neither proposal modifies, as a condorcet
voting mechanism, does not suffer directly from too many options on the ballot. While it is desirable to make sure the number of options on the ballot is not extremely high for reasons of practicality and voter
fatigue, it is nonetheless of crucial importance that all the *relevant* options are represented on the ballot, so that the vote outcome is not questioned for the mere fact that a particular option was not
represented on the ballot. Making this possible requires that there is sufficient time to discuss all relevant opinions.
Russ' proposal introduces a hard limit of 3 weeks to any and all ballot processes, assuming that that will almost always be enough, and relying
on withdrawing and restarting the voting process in extreme cases where
it turns out more time is needed; in Russ' proposal, doing so would
increase the discussion time by another two weeks at least (or one if
the DPL reduces the discussion time).
In controversial votes, I believe it is least likely for all ballot
proposers to be willing to use this escape hatch of withdrawing the vote
and restarting the process; and at the same time, controversial votes
are the most likely to need a lot of discussion to build a correct
ballot, which implies they would be most likely to need some extra time
-- though not necessarily two more weeks -- for the ballot to be
complete.
At the same time, I am not insensitive to arguments of predictability, diminishing returns, and process abuse which seem to be the main
arguments in favour of a hard time limit at three weeks.
For this reason, my proposal does not introduce a hard limit, and
*always* makes it theoretically possible to increase the discussion
time, but does so in a way that extending the discussion time becomes
harder and harder as time goes on. I believe it is better for the constitution to allow a group of people to have a short amount of extra
time so they can finish their proposed ballot option, than to require
the full discussion period to be restarted through the withdrawal and
restart escape hatch. At the same time, this escape hatch is not
removed, although I expect it to be less likely to be used.
The proposed mechanism sets the initial discussion time to 1 week, but
allows it to be extended reasonably easily to 2 or 3 weeks, makes it
somewhat harder to reach 4 weeks, and makes it highly unlikely (but
still possible) to go beyond that.
Text of the GR
==============
The Debian Developers, by way of General Resolution, amend the Debian constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Sections 4 through 7
--------------------
Same changes as in Russ' proposal
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Strike the sentence "The maximum discussion period is 3 weeks".
A.1.4. Strike in its entirety
A.1.5. Rename to A.1.4.
A.1.6. Strike in its entirety
A.1.7. Rename to A.1.5.
After A.2, insert:
A.3. Extending the discussion time.
1. When less than 48 hours remain in the discussion time, any Developer
may propose an extension to the discussion time, subject to the
limitations of §A.3.3. These extensions may be seconded according to
the same rules that apply to new ballot options.
2. As soon as a time extension has received the required number of
seconds, these seconds are locked in and cannot be withdrawn, and the
time extension is active.
3. When a time extension has received the required number of seconds,
its proposers and seconders may no longer propose or second any
further time extension for the same ballot, and any further seconds
for the same extension proposal will be ignored for the purpose of
this paragraph. In case of doubt, the Project Secretary decides how
the order of seconds is determined.
4. The first two successful time extensions will extend the discussion
time by one week; any further time extensions will extend the
discussion time by 72 hours.
5. Once the discussion time is longer than 4 weeks, any Developer may
object to further time extensions. Developers who have previously
proposed or seconded a time extension may object as well. If the
number of objections outweigh the proposer and their seconders,
including seconders who will be ignored as per §A.3.3, the time
extension will not be active and the discussion time does not change.
A.3. Rename to A.4.
A.4. Rename to A.5.
A.5. Rename (back) to A.6.
Seconded.
Text of the GR
==============
The Debian Developers, by way of General Resolution, amend the Debian constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Sections 4 through 7
--------------------
Same changes as in Russ' proposal
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Strike the sentence "The maximum discussion period is 3 weeks".
A.1.4. Strike in its entirety
A.1.5. Rename to A.1.4.
A.1.6. Strike in its entirety
A.1.7. Rename to A.1.5.
After A.2, insert:
A.3. Extending the discussion time.
1. When less than 48 hours remain in the discussion time, any Developer
may propose an extension to the discussion time, subject to the
limitations of §A.3.3. These extensions may be seconded according to
the same rules that apply to new ballot options.
2. As soon as a time extension has received the required number of
seconds, these seconds are locked in and cannot be withdrawn, and the
time extension is active.
3. When a time extension has received the required number of seconds,
its proposers and seconders may no longer propose or second any
further time extension for the same ballot, and any further seconds
for the same extension proposal will be ignored for the purpose of
this paragraph. In case of doubt, the Project Secretary decides how
the order of seconds is determined.
4. The first two successful time extensions will extend the discussion
time by one week; any further time extensions will extend the
discussion time by 72 hours.
5. Once the discussion time is longer than 4 weeks, any Developer may
object to further time extensions. Developers who have previously
proposed or seconded a time extension may object as well. If the
number of objections outweigh the proposer and their seconders,
including seconders who will be ignored as per §A.3.3, the time
extension will not be active and the discussion time does not change.
A.3. Rename to A.4.
A.4. Rename to A.5.
A.5. Rename (back) to A.6.
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Strike the sentence "The maximum discussion period is 3 weeks".
.... aaand this should've been signed. Good morning.
Text of the GR
==============
The Debian Developers, by way of General Resolution, amend the Debian constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Sections 4 through 7
--------------------
Copy from Russ' proposal, replacing cross-references to §A.5 by §A.6, where relevant.
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Replace the sentence "The minimum discussion period is 2 weeks."
by "The initial discussion period is 1 week." Strike the sentence
"The maximum discussion period is 3 weeks".
A.1.4. Strike in its entirety
A.1.5. Rename to A.1.4.
A.1.6. Strike in its entirety
A.1.7. Rename to A.1.5.
After A.2, insert:
A.3. Extending the discussion time.
1. When less than 48 hours remain in the discussion time, any Developer
may propose an extension to the discussion time, subject to the
limitations of §A.3.3. These extensions may be seconded according to
the same rules that apply to new ballot options.
2. As soon as a time extension has received the required number of
seconds, these seconds are locked in and cannot be withdrawn, and the
time extension is active.
3. When a time extension has received the required number of seconds,
its proposers and seconders may no longer propose or second any
further time extension for the same ballot, and any further seconds
for the same extension proposal will be ignored for the purpose of
this paragraph. In case of doubt, the Project Secretary decides how
the order of seconds is determined.
4. The first two successful time extensions will extend the discussion
time by one week; any further time extensions will extend the
discussion time by 72 hours.
5. Once the discussion time is longer than 4 weeks, any Developer may
object to further time extensions. Developers who have previously
proposed or seconded a time extension may object as well. If the
number of objections outweigh the proposer and their seconders,
including seconders who will be ignored as per §A.3.3, the time
extension will not be active and the discussion time does not change.
A.3. Rename to A.4.
A.3.6 (now A.4.6): replace 'A.3.4' by 'A.4.4'.
A.4. Rename to A.5.
A.4.2 (now A.5.2): replace '§A.5' by '§A.6'.
A.5. Rename (back) to A.6.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
On Mon, Nov 22, 2021 at 05:15:34PM +0200, Wouter Verhelst wrote:
[...]
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Strike the sentence "The maximum discussion period is 3 weeks".
This should additionally say,
Replace the sentence "The minimum discussion period is 2 weeks." by
"The initial discussion period is 1 week."
as my proposal does not allow the DPL to reduce the discussion time, and instead reduces the discussion time always, relying on the time
extension procedure to lengthen it, if required (which the DPL can use without seconds, once).
Since both Russ and myself seem to be having issues here, in order to better understand the proposed changes, I have made https://salsa.debian.org/wouter/webwml/-/blob/constitution-russ/english/devel/constitution.wml
(which is a version of the constitution with the changes as proposed by Russ) and https://salsa.debian.org/wouter/webwml/-/blob/constitution-wouter/english/devel/constitution.wml
(with the required changes as per my proposal). While doing so, I
realized there were a few cross-references still that I needed to update
as well.
Russ, please review the patch I wrote, so as to make sure I haven't made any mistakes in your proposal.
All this changes my proposal to the below. I would appreciate if my seconders would re-affirm that they agree with the changes I propose,
and apologies for the mess.
Rationale
=========
Much of the rationale of Russ' proposal still applies, and indeed this amendment builds on it. However, the way the timing works is different,
on purpose.
Our voting system, which neither proposal modifies, as a condorcet
voting mechanism, does not suffer directly from too many options on the ballot. While it is desirable to make sure the number of options on the ballot is not extremely high for reasons of practicality and voter
fatigue, it is nonetheless of crucial importance that all the *relevant* options are represented on the ballot, so that the vote outcome is not questioned for the mere fact that a particular option was not
represented on the ballot. Making this possible requires that there is sufficient time to discuss all relevant opinions.
Russ' proposal introduces a hard limit of 3 weeks to any and all ballot processes, assuming that that will almost always be enough, and relying
on withdrawing and restarting the voting process in extreme cases where
it turns out more time is needed; in Russ' proposal, doing so would increase the discussion time by another two weeks at least (or one if
the DPL reduces the discussion time).
In controversial votes, I believe it is least likely for all ballot proposers to be willing to use this escape hatch of withdrawing the vote and restarting the process; and at the same time, controversial votes
are the most likely to need a lot of discussion to build a correct
ballot, which implies they would be most likely to need some extra time
-- though not necessarily two more weeks -- for the ballot to be
complete.
At the same time, I am not insensitive to arguments of predictability, diminishing returns, and process abuse which seem to be the main
arguments in favour of a hard time limit at three weeks.
For this reason, my proposal does not introduce a hard limit, and
*always* makes it theoretically possible to increase the discussion
time, but does so in a way that extending the discussion time becomes harder and harder as time goes on. I believe it is better for the constitution to allow a group of people to have a short amount of extra time so they can finish their proposed ballot option, than to require
the full discussion period to be restarted through the withdrawal and restart escape hatch. At the same time, this escape hatch is not
removed, although I expect it to be less likely to be used.
The proposed mechanism sets the initial discussion time to 1 week, but allows it to be extended reasonably easily to 2 or 3 weeks, makes it somewhat harder to reach 4 weeks, and makes it highly unlikely (but
still possible) to go beyond that.
Text of the GR
==============
The Debian Developers, by way of General Resolution, amend the Debian constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Sections 4 through 7
--------------------
Copy from Russ' proposal, replacing cross-references to §A.5 by §A.6, where relevant.
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Replace the sentence "The minimum discussion period is 2 weeks."
by "The initial discussion period is 1 week." Strike the sentence
"The maximum discussion period is 3 weeks".
A.1.4. Strike in its entirety
A.1.5. Rename to A.1.4.
A.1.6. Strike in its entirety
A.1.7. Rename to A.1.5.
After A.2, insert:
A.3. Extending the discussion time.
1. When less than 48 hours remain in the discussion time, any Developer
may propose an extension to the discussion time, subject to the
limitations of §A.3.3. These extensions may be seconded according to
the same rules that apply to new ballot options.
2. As soon as a time extension has received the required number of
seconds, these seconds are locked in and cannot be withdrawn, and the
time extension is active.
3. When a time extension has received the required number of seconds,
its proposers and seconders may no longer propose or second any
further time extension for the same ballot, and any further seconds
for the same extension proposal will be ignored for the purpose of
this paragraph. In case of doubt, the Project Secretary decides how
the order of seconds is determined.
4. The first two successful time extensions will extend the discussion
time by one week; any further time extensions will extend the
discussion time by 72 hours.
5. Once the discussion time is longer than 4 weeks, any Developer may
object to further time extensions. Developers who have previously
proposed or seconded a time extension may object as well. If the
number of objections outweigh the proposer and their seconders,
including seconders who will be ignored as per §A.3.3, the time
extension will not be active and the discussion time does not change.
A.3. Rename to A.4.
A.3.6 (now A.4.6): replace 'A.3.4' by 'A.4.4'.
A.4. Rename to A.5.
A.4.2 (now A.5.2): replace '§A.5' by '§A.6'.
A.5. Rename (back) to A.6.
I *believe* you'll find it in english/devel/constitution.wml in git@salsa.debian.org:webmaster-team/webwml
(*After* the GR when the change is actually going to be made please note
that there are files like english/devel/constitution.1.$x.wml...)
Since both Russ and myself seem to be having issues here, in order to
better understand the proposed changes, I have made https://salsa.debian.org/wouter/webwml/-/blob/constitution-russ/english/devel/constitution.wml
(which is a version of the constitution with the changes as proposed by
Russ) and https://salsa.debian.org/wouter/webwml/-/blob/constitution-wouter/english/devel/constitution.wml
(with the required changes as per my proposal). While doing so, I
realized there were a few cross-references still that I needed to update
as well.
Russ, please review the patch I wrote, so as to make sure I haven't made
any mistakes in your proposal.
Rationale
=========
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Replace the sentence "The minimum discussion period is 2 weeks."
by "The initial discussion period is 1 week." Strike the sentence
"The maximum discussion period is 3 weeks".
A.1.4. Strike in its entirety
A.1.5. Rename to A.1.4.
After A.2, insert:
A.3. Extending the discussion time.
1. When less than 48 hours remain in the discussion time, any Developer
may propose an extension to the discussion time, subject to the
limitations of §A.3.3. These extensions may be seconded according to
the same rules that apply to new ballot options.
2. As soon as a time extension has received the required number of
seconds, these seconds are locked in and cannot be withdrawn, and the
time extension is active.
3. When a time extension has received the required number of seconds,
its proposers and seconders may no longer propose or second any
further time extension for the same ballot, and any further seconds
for the same extension proposal will be ignored for the purpose of
this paragraph. In case of doubt, the Project Secretary decides how
the order of seconds is determined.
Because of this (and others), can I suggest that the ballot option be specified as a wdiff to the existing constitution?
Kurt Roeckx <kurt@roeckx.be> writes:
On Sat, Nov 20, 2021 at 10:04:07AM -0800, Russ Allbery wrote:
I propose the following General Resolution, which will require a 3:1
majority, and am seeking sponsors.
This is now at:
https://www.debian.org/vote/2021/vote_003
Thank you!
I did not add any of the corrections, you did not sign them, you
indicated you'll have more later.
Yes, indeed, no problem. Currently, I'm aware of only one correction
4. The addition of a ballot option or the change via a amendment of a
I propose the following General Resolution, which will require a 3:1 majority, and am seeking sponsors.
On Sat, Nov 20, 2021 at 10:04:07AM -0800, Russ Allbery wrote:
I propose the following General Resolution, which will require a 3:1
majority, and am seeking sponsors.
This is now at:
https://www.debian.org/vote/2021/vote_003
I did not add any of the corrections, you did not sign them, you
indicated you'll have more later.
Russ Allbery <rra@debian.org> wrote on 23/11/2021 at 23:39:51+0100:
Yes, indeed, no problem. Currently, I'm aware of only one correction
I pointed out a typo, but probably did not emphasize it clearly enough. :)
4. The addition of a ballot option or the change via a amendment of a
I think it's "an amendment", not "a amendment".
Wouter Verhelst <wouter@debian.org> writes:
Since both Russ and myself seem to be having issues here, in order to better understand the proposed changes, I have made https://salsa.debian.org/wouter/webwml/-/blob/constitution-russ/english/devel/constitution.wml
(which is a version of the constitution with the changes as proposed by Russ) and https://salsa.debian.org/wouter/webwml/-/blob/constitution-wouter/english/devel/constitution.wml
(with the required changes as per my proposal). While doing so, I
realized there were a few cross-references still that I needed to update
as well.
Thank you so much! This saved me tons of time.
Russ, please review the patch I wrote, so as to make sure I haven't made any mistakes in your proposal.
I confirm that you accurately reflected the changes from my proposal
except that your version (quite reasonably) doesn't include the minor
change to add "is" in A.2.3.
I did a bit of reformatting with an eye to such a diff eventually being merged that makes the HTML style match what appeared to be the prevailing style in the rest of the document and will use that version to generate an "official" diff of my proposal. Not sure whether you want to rebase on
that version or not; I can push it up to Salsa in my own repo, or give you
a PR against your repo, or whatever else is convenient.
I'm happy to help with that rebasing if you'd like and give you a PR for
your branch as well. It's the least that I can do after you did all the
work of recasting my proposal in webwml.
Rationale
=========
I just wanted to say how much I appreciated the collaborative and
collegial tone of this rationale even though by necessity you're laying
out how you disagree with my proposal. It's really excellent. And in general I've been very happy with how constructive and positive this whole discussion has been.
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Replace the sentence "The minimum discussion period is 2 weeks."
by "The initial discussion period is 1 week." Strike the sentence
"The maximum discussion period is 3 weeks".
A.1.4. Strike in its entirety
A.1.5. Rename to A.1.4.
I think you also want to remove:
In this case the length of the discussion period is not changed.
from this section because that's only there because of the provision in
A.1.4 that you are removing. You can probably do this as a minor change since it doesn't affect the meaning.
After A.2, insert:
A.3. Extending the discussion time.
1. When less than 48 hours remain in the discussion time, any Developer
may propose an extension to the discussion time, subject to the
limitations of A.3.3. These extensions may be seconded according to
the same rules that apply to new ballot options.
Minor point: We routinely in casual discussion use the term "seconded,"
but the constitution uniformly uses "sponsor" and the word "seconded"
doesn't appear anywhere in the constitution. I adjusted my change while I was drafting it to stick with that language and you may want to make the
same change here.
Same note for points 2 and 3.
2. As soon as a time extension has received the required number of
seconds, these seconds are locked in and cannot be withdrawn, and the
time extension is active.
3. When a time extension has received the required number of seconds,
its proposers and seconders may no longer propose or second any
further time extension for the same ballot, and any further seconds
for the same extension proposal will be ignored for the purpose of
this paragraph. In case of doubt, the Project Secretary decides how
the order of seconds is determined.
"this paragraph" sounds like it may only be applying to point 3, and I
think you mean for the purposes of this whole section. You may want to
word this as "for the purposes of this section" instead.
1. Any member of the Technical Committee may propose a resolution. >> This creates an initial two-option ballot, the other option
being the default option of "Further discussion." The proposer >> of the resolution becomes the proposer of the ballot option.
Suggest making this "None of the above" instead of "Further discussion"
to avoid two different default options for TC decisions vs project decisions.
This was discussed briefly earlier, and for whatever it's worth was intentional. My reasoning was that when the TC is asked to make a
decision, "None of the above" doesn't conclude that process. In the TC
case, it does seem to really mean "further discussion" in the sense that
the TC hasn't resolved the issue in front of them and has to keep
discussing it.
That said, I don't feel strongly about this and can change this if folks would prefer, particularly if TC members don't think that's the right way
to go.
Suggest making this "None of the above" instead of "Further discussion" to avoid two different default options for TC decisions vs project decisions.
I would prefer the change to extend also to the TC votes. I think
it's clear that "none of the above" means we would not have an
outcome to present, but I feel "none of the above" to be
clearer.
Also a TC member but writing only on my own behalf. I agree with Gunnar
that NOTA seems fine as a default for TC decisions (except for choosing
the TC chair, which is special-cased to have no default).
.... aaand this should've been signed. Good morning.
On Tue, Nov 23, 2021 at 09:50:14AM +0200, Wouter Verhelst wrote:
... and then I realize I *also* made a (small, but crucial) mistake:
On Mon, Nov 22, 2021 at 05:15:34PM +0200, Wouter Verhelst wrote:
[...]
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Strike the sentence "The maximum discussion period is 3 weeks".
This should additionally say,
Replace the sentence "The minimum discussion period is 2 weeks." by
"The initial discussion period is 1 week."
as my proposal does not allow the DPL to reduce the discussion time, and
instead reduces the discussion time always, relying on the time
extension procedure to lengthen it, if required (which the DPL can use
without seconds, once).
Since both Russ and myself seem to be having issues here, in order to
better understand the proposed changes, I have made
https://salsa.debian.org/wouter/webwml/-/blob/constitution-russ/english/devel/constitution.wml
(which is a version of the constitution with the changes as proposed by
Russ) and
https://salsa.debian.org/wouter/webwml/-/blob/constitution-wouter/english/devel/constitution.wml
(with the required changes as per my proposal). While doing so, I
realized there were a few cross-references still that I needed to update
as well.
Russ, please review the patch I wrote, so as to make sure I haven't made
any mistakes in your proposal.
All this changes my proposal to the below. I would appreciate if my
seconders would re-affirm that they agree with the changes I propose,
and apologies for the mess.
Rationale
=========
Much of the rationale of Russ' proposal still applies, and indeed this
amendment builds on it. However, the way the timing works is different,
on purpose.
Our voting system, which neither proposal modifies, as a condorcet
voting mechanism, does not suffer directly from too many options on the
ballot. While it is desirable to make sure the number of options on the
ballot is not extremely high for reasons of practicality and voter
fatigue, it is nonetheless of crucial importance that all the *relevant*
options are represented on the ballot, so that the vote outcome is not
questioned for the mere fact that a particular option was not
represented on the ballot. Making this possible requires that there is
sufficient time to discuss all relevant opinions.
Russ' proposal introduces a hard limit of 3 weeks to any and all ballot
processes, assuming that that will almost always be enough, and relying
on withdrawing and restarting the voting process in extreme cases where
it turns out more time is needed; in Russ' proposal, doing so would
increase the discussion time by another two weeks at least (or one if
the DPL reduces the discussion time).
In controversial votes, I believe it is least likely for all ballot
proposers to be willing to use this escape hatch of withdrawing the vote
and restarting the process; and at the same time, controversial votes
are the most likely to need a lot of discussion to build a correct
ballot, which implies they would be most likely to need some extra time
-- though not necessarily two more weeks -- for the ballot to be
complete.
At the same time, I am not insensitive to arguments of predictability,
diminishing returns, and process abuse which seem to be the main
arguments in favour of a hard time limit at three weeks.
For this reason, my proposal does not introduce a hard limit, and
*always* makes it theoretically possible to increase the discussion
time, but does so in a way that extending the discussion time becomes
harder and harder as time goes on. I believe it is better for the
constitution to allow a group of people to have a short amount of extra
time so they can finish their proposed ballot option, than to require
the full discussion period to be restarted through the withdrawal and
restart escape hatch. At the same time, this escape hatch is not
removed, although I expect it to be less likely to be used.
The proposed mechanism sets the initial discussion time to 1 week, but
allows it to be extended reasonably easily to 2 or 3 weeks, makes it
somewhat harder to reach 4 weeks, and makes it highly unlikely (but
still possible) to go beyond that.
Text of the GR
==============
The Debian Developers, by way of General Resolution, amend the Debian
constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Sections 4 through 7
--------------------
Copy from Russ' proposal, replacing cross-references to §A.5 by §A.6,
where relevant.
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Replace the sentence "The minimum discussion period is 2 weeks."
by "The initial discussion period is 1 week." Strike the sentence
"The maximum discussion period is 3 weeks".
A.1.4. Strike in its entirety
A.1.5. Rename to A.1.4.
A.1.6. Strike in its entirety
A.1.7. Rename to A.1.5.
After A.2, insert:
A.3. Extending the discussion time.
1. When less than 48 hours remain in the discussion time, any Developer
may propose an extension to the discussion time, subject to the
limitations of §A.3.3. These extensions may be seconded according to
the same rules that apply to new ballot options.
2. As soon as a time extension has received the required number of
seconds, these seconds are locked in and cannot be withdrawn, and the
time extension is active.
3. When a time extension has received the required number of seconds,
its proposers and seconders may no longer propose or second any
further time extension for the same ballot, and any further seconds
for the same extension proposal will be ignored for the purpose of
this paragraph. In case of doubt, the Project Secretary decides how
the order of seconds is determined.
4. The first two successful time extensions will extend the discussion
time by one week; any further time extensions will extend the
discussion time by 72 hours.
5. Once the discussion time is longer than 4 weeks, any Developer may
object to further time extensions. Developers who have previously
proposed or seconded a time extension may object as well. If the
number of objections outweigh the proposer and their seconders,
including seconders who will be ignored as per §A.3.3, the time
extension will not be active and the discussion time does not change.
A.3. Rename to A.4.
A.3.6 (now A.4.6): replace 'A.3.4' by 'A.4.4'.
A.4. Rename to A.5.
A.4.2 (now A.5.2): replace '§A.5' by '§A.6'.
A.5. Rename (back) to A.6.
I propose the following General Resolution, which will require a 3:1 majority, and am seeking sponsors.
Could you provide this as a patches series or similar ?
I tried to read it several time and each time I felt I was missing the context, that fundamentally I did not understand what the result would
be.
On Sat, Nov 20, 2021 at 10:04:07AM -0800, Russ Allbery wrote:
I propose the following General Resolution, which will require a 3:1
majority, and am seeking sponsors.
Could you provide this as a patches series or similar ?
I tried to read it several time and each time I felt I was missing the context, that fundamentally I did not understand what the result would
be.
Here is a Salsa diff with the current version of the constitution:
https://salsa.debian.org/rra/webwml/-/compare/master...gr-2021-003?from_project_id=65952
On Tue, Nov 23, 2021 at 09:50:14AM +0200, Wouter Verhelst wrote:
... and then I realize I *also* made a (small, but crucial) mistake:
On Mon, Nov 22, 2021 at 05:15:34PM +0200, Wouter Verhelst wrote:
[...]
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Strike the sentence "The maximum discussion period is 3 weeks".
This should additionally say,
Replace the sentence "The minimum discussion period is 2 weeks." by
"The initial discussion period is 1 week."
as my proposal does not allow the DPL to reduce the discussion time, and instead reduces the discussion time always, relying on the time
extension procedure to lengthen it, if required (which the DPL can use without seconds, once).
Since both Russ and myself seem to be having issues here, in order to better understand the proposed changes, I have made https://salsa.debian.org/wouter/webwml/-/blob/constitution-russ/english/devel/constitution.wml
(which is a version of the constitution with the changes as proposed by Russ) and https://salsa.debian.org/wouter/webwml/-/blob/constitution-wouter/english/devel/constitution.wml
(with the required changes as per my proposal). While doing so, I
realized there were a few cross-references still that I needed to update
as well.
Russ, please review the patch I wrote, so as to make sure I haven't made any mistakes in your proposal.
All this changes my proposal to the below. I would appreciate if my seconders would re-affirm that they agree with the changes I propose,
and apologies for the mess.
Rationale
=========
Much of the rationale of Russ' proposal still applies, and indeed this amendment builds on it. However, the way the timing works is different,
on purpose.
Our voting system, which neither proposal modifies, as a condorcet
voting mechanism, does not suffer directly from too many options on the ballot. While it is desirable to make sure the number of options on the ballot is not extremely high for reasons of practicality and voter
fatigue, it is nonetheless of crucial importance that all the *relevant* options are represented on the ballot, so that the vote outcome is not questioned for the mere fact that a particular option was not
represented on the ballot. Making this possible requires that there is sufficient time to discuss all relevant opinions.
Russ' proposal introduces a hard limit of 3 weeks to any and all ballot processes, assuming that that will almost always be enough, and relying
on withdrawing and restarting the voting process in extreme cases where
it turns out more time is needed; in Russ' proposal, doing so would increase the discussion time by another two weeks at least (or one if
the DPL reduces the discussion time).
In controversial votes, I believe it is least likely for all ballot proposers to be willing to use this escape hatch of withdrawing the vote and restarting the process; and at the same time, controversial votes
are the most likely to need a lot of discussion to build a correct
ballot, which implies they would be most likely to need some extra time
-- though not necessarily two more weeks -- for the ballot to be
complete.
At the same time, I am not insensitive to arguments of predictability, diminishing returns, and process abuse which seem to be the main
arguments in favour of a hard time limit at three weeks.
For this reason, my proposal does not introduce a hard limit, and
*always* makes it theoretically possible to increase the discussion
time, but does so in a way that extending the discussion time becomes harder and harder as time goes on. I believe it is better for the constitution to allow a group of people to have a short amount of extra time so they can finish their proposed ballot option, than to require
the full discussion period to be restarted through the withdrawal and restart escape hatch. At the same time, this escape hatch is not
removed, although I expect it to be less likely to be used.
The proposed mechanism sets the initial discussion time to 1 week, but allows it to be extended reasonably easily to 2 or 3 weeks, makes it somewhat harder to reach 4 weeks, and makes it highly unlikely (but
still possible) to go beyond that.
Text of the GR
==============
The Debian Developers, by way of General Resolution, amend the Debian constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Sections 4 through 7
--------------------
Copy from Russ' proposal, replacing cross-references to A.5 by A.6,
where relevant.
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Replace the sentence "The minimum discussion period is 2 weeks."
by "The initial discussion period is 1 week." Strike the sentence
"The maximum discussion period is 3 weeks".
A.1.4. Strike in its entirety
A.1.5. Rename to A.1.4.
A.1.6. Strike in its entirety
A.1.7. Rename to A.1.5.
After A.2, insert:
A.3. Extending the discussion time.
1. When less than 48 hours remain in the discussion time, any Developer
may propose an extension to the discussion time, subject to the
limitations of A.3.3. These extensions may be seconded according to
the same rules that apply to new ballot options.
2. As soon as a time extension has received the required number of
seconds, these seconds are locked in and cannot be withdrawn, and the
time extension is active.
3. When a time extension has received the required number of seconds,
its proposers and seconders may no longer propose or second any
further time extension for the same ballot, and any further seconds
for the same extension proposal will be ignored for the purpose of
this paragraph. In case of doubt, the Project Secretary decides how
the order of seconds is determined.
4. The first two successful time extensions will extend the discussion
time by one week; any further time extensions will extend the
discussion time by 72 hours.
5. Once the discussion time is longer than 4 weeks, any Developer may
object to further time extensions. Developers who have previously
proposed or seconded a time extension may object as well. If the
number of objections outweigh the proposer and their seconders,
including seconders who will be ignored as per A.3.3, the time
extension will not be active and the discussion time does not change.
A.3. Rename to A.4.
A.3.6 (now A.4.6): replace 'A.3.4' by 'A.4.4'.
A.4. Rename to A.5.
A.4.2 (now A.5.2): replace 'A.5' by 'A.6'.
A.5. Rename (back) to A.6.
... and then I realize I *also* made a (small, but crucial) mistake:
On Mon, Nov 22, 2021 at 05:15:34PM +0200, Wouter Verhelst wrote:
[...]
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Strike the sentence "The maximum discussion period is 3 weeks".
This should additionally say,
Replace the sentence "The minimum discussion period is 2 weeks." by
"The initial discussion period is 1 week."
as my proposal does not allow the DPL to reduce the discussion time, and instead reduces the discussion time always, relying on the time
extension procedure to lengthen it, if required (which the DPL can use without seconds, once).
Since both Russ and myself seem to be having issues here, in order to
better understand the proposed changes, I have made https://salsa.debian.org/wouter/webwml/-/blob/constitution-russ/english/devel/constitution.wml
(which is a version of the constitution with the changes as proposed by
Russ) and https://salsa.debian.org/wouter/webwml/-/blob/constitution-wouter/english/devel/constitution.wml
(with the required changes as per my proposal). While doing so, I
realized there were a few cross-references still that I needed to update
as well.
Russ, please review the patch I wrote, so as to make sure I haven't made
any mistakes in your proposal.
All this changes my proposal to the below. I would appreciate if my
seconders would re-affirm that they agree with the changes I propose,
and apologies for the mess.
Rationale
=========
Much of the rationale of Russ' proposal still applies, and indeed this amendment builds on it. However, the way the timing works is different,
on purpose.
Our voting system, which neither proposal modifies, as a condorcet
voting mechanism, does not suffer directly from too many options on the ballot. While it is desirable to make sure the number of options on the ballot is not extremely high for reasons of practicality and voter
fatigue, it is nonetheless of crucial importance that all the *relevant* options are represented on the ballot, so that the vote outcome is not questioned for the mere fact that a particular option was not
represented on the ballot. Making this possible requires that there is sufficient time to discuss all relevant opinions.
Russ' proposal introduces a hard limit of 3 weeks to any and all ballot processes, assuming that that will almost always be enough, and relying
on withdrawing and restarting the voting process in extreme cases where
it turns out more time is needed; in Russ' proposal, doing so would
increase the discussion time by another two weeks at least (or one if
the DPL reduces the discussion time).
In controversial votes, I believe it is least likely for all ballot
proposers to be willing to use this escape hatch of withdrawing the vote
and restarting the process; and at the same time, controversial votes
are the most likely to need a lot of discussion to build a correct
ballot, which implies they would be most likely to need some extra time
-- though not necessarily two more weeks -- for the ballot to be
complete.
At the same time, I am not insensitive to arguments of predictability, diminishing returns, and process abuse which seem to be the main
arguments in favour of a hard time limit at three weeks.
For this reason, my proposal does not introduce a hard limit, and
*always* makes it theoretically possible to increase the discussion
time, but does so in a way that extending the discussion time becomes
harder and harder as time goes on. I believe it is better for the constitution to allow a group of people to have a short amount of extra
time so they can finish their proposed ballot option, than to require
the full discussion period to be restarted through the withdrawal and
restart escape hatch. At the same time, this escape hatch is not
removed, although I expect it to be less likely to be used.
The proposed mechanism sets the initial discussion time to 1 week, but
allows it to be extended reasonably easily to 2 or 3 weeks, makes it
somewhat harder to reach 4 weeks, and makes it highly unlikely (but
still possible) to go beyond that.
Text of the GR
==============
The Debian Developers, by way of General Resolution, amend the Debian constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Sections 4 through 7
--------------------
Copy from Russ' proposal, replacing cross-references to §A.5 by §A.6,
where relevant.
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Replace the sentence "The minimum discussion period is 2 weeks."
by "The initial discussion period is 1 week." Strike the sentence
"The maximum discussion period is 3 weeks".
A.1.4. Strike in its entirety
A.1.5. Rename to A.1.4.
A.1.6. Strike in its entirety
A.1.7. Rename to A.1.5.
After A.2, insert:
A.3. Extending the discussion time.
1. When less than 48 hours remain in the discussion time, any Developer
may propose an extension to the discussion time, subject to the
limitations of §A.3.3. These extensions may be seconded according to
the same rules that apply to new ballot options.
2. As soon as a time extension has received the required number of
seconds, these seconds are locked in and cannot be withdrawn, and the
time extension is active.
3. When a time extension has received the required number of seconds,
its proposers and seconders may no longer propose or second any
further time extension for the same ballot, and any further seconds
for the same extension proposal will be ignored for the purpose of
this paragraph. In case of doubt, the Project Secretary decides how
the order of seconds is determined.
4. The first two successful time extensions will extend the discussion
time by one week; any further time extensions will extend the
discussion time by 72 hours.
5. Once the discussion time is longer than 4 weeks, any Developer may
object to further time extensions. Developers who have previously
proposed or seconded a time extension may object as well. If the
number of objections outweigh the proposer and their seconders,
including seconders who will be ignored as per §A.3.3, the time
extension will not be active and the discussion time does not change.
A.3. Rename to A.4.
A.3.6 (now A.4.6): replace 'A.3.4' by 'A.4.4'.
A.4. Rename to A.5.
A.4.2 (now A.5.2): replace '§A.5' by '§A.6'.
A.5. Rename (back) to A.6.
.... aaand this should've been signed. Good morning.
On Tue, Nov 23, 2021 at 09:50:14AM +0200, Wouter Verhelst wrote:
All this changes my proposal to the below. I would appreciate if my
seconders would re-affirm that they agree with the changes I propose,
and apologies for the mess.
Rationale
=========
Much of the rationale of Russ' proposal still applies, and indeed this
amendment builds on it. However, the way the timing works is different,
on purpose.
Our voting system, which neither proposal modifies, as a condorcet
voting mechanism, does not suffer directly from too many options on the
ballot. While it is desirable to make sure the number of options on the
ballot is not extremely high for reasons of practicality and voter
fatigue, it is nonetheless of crucial importance that all the *relevant*
options are represented on the ballot, so that the vote outcome is not
questioned for the mere fact that a particular option was not
represented on the ballot. Making this possible requires that there is
sufficient time to discuss all relevant opinions.
Russ' proposal introduces a hard limit of 3 weeks to any and all ballot
processes, assuming that that will almost always be enough, and relying
on withdrawing and restarting the voting process in extreme cases where
it turns out more time is needed; in Russ' proposal, doing so would
increase the discussion time by another two weeks at least (or one if
the DPL reduces the discussion time).
In controversial votes, I believe it is least likely for all ballot
proposers to be willing to use this escape hatch of withdrawing the vote
and restarting the process; and at the same time, controversial votes
are the most likely to need a lot of discussion to build a correct
ballot, which implies they would be most likely to need some extra time
-- though not necessarily two more weeks -- for the ballot to be
complete.
At the same time, I am not insensitive to arguments of predictability,
diminishing returns, and process abuse which seem to be the main
arguments in favour of a hard time limit at three weeks.
For this reason, my proposal does not introduce a hard limit, and
*always* makes it theoretically possible to increase the discussion
time, but does so in a way that extending the discussion time becomes
harder and harder as time goes on. I believe it is better for the
constitution to allow a group of people to have a short amount of extra
time so they can finish their proposed ballot option, than to require
the full discussion period to be restarted through the withdrawal and
restart escape hatch. At the same time, this escape hatch is not
removed, although I expect it to be less likely to be used.
The proposed mechanism sets the initial discussion time to 1 week, but
allows it to be extended reasonably easily to 2 or 3 weeks, makes it
somewhat harder to reach 4 weeks, and makes it highly unlikely (but
still possible) to go beyond that.
Text of the GR
==============
The Debian Developers, by way of General Resolution, amend the Debian
constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Sections 4 through 7
--------------------
Copy from Russ' proposal, replacing cross-references to §A.5 by §A.6,
where relevant.
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Replace the sentence "The minimum discussion period is 2 weeks."
by "The initial discussion period is 1 week." Strike the sentence
"The maximum discussion period is 3 weeks".
A.1.4. Strike in its entirety
A.1.5. Rename to A.1.4.
A.1.6. Strike in its entirety
A.1.7. Rename to A.1.5.
After A.2, insert:
A.3. Extending the discussion time.
1. When less than 48 hours remain in the discussion time, any Developer
may propose an extension to the discussion time, subject to the
limitations of §A.3.3. These extensions may be seconded according to
the same rules that apply to new ballot options.
2. As soon as a time extension has received the required number of
seconds, these seconds are locked in and cannot be withdrawn, and the
time extension is active.
3. When a time extension has received the required number of seconds,
its proposers and seconders may no longer propose or second any
further time extension for the same ballot, and any further seconds
for the same extension proposal will be ignored for the purpose of
this paragraph. In case of doubt, the Project Secretary decides how
the order of seconds is determined.
4. The first two successful time extensions will extend the discussion
time by one week; any further time extensions will extend the
discussion time by 72 hours.
5. Once the discussion time is longer than 4 weeks, any Developer may
object to further time extensions. Developers who have previously
proposed or seconded a time extension may object as well. If the
number of objections outweigh the proposer and their seconders,
including seconders who will be ignored as per §A.3.3, the time
extension will not be active and the discussion time does not change.
A.3. Rename to A.4.
A.3.6 (now A.4.6): replace 'A.3.4' by 'A.4.4'.
A.4. Rename to A.5.
A.4.2 (now A.5.2): replace '§A.5' by '§A.6'.
A.5. Rename (back) to A.6.
Wouter Verhelst <w@uter.be> writes:
.... aaand this should've been signed. Good morning.
On Tue, Nov 23, 2021 at 09:50:14AM +0200, Wouter Verhelst wrote:
All this changes my proposal to the below. I would appreciate if my
seconders would re-affirm that they agree with the changes I propose,
and apologies for the mess.
I think this is at or near the required number of sponsors
Text of the GR
==============
The Debian Developers, by way of General Resolution, amend the Debian constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Sections 4 through 7
--------------------
Copy from Russ' proposal, replacing cross-references to A.5 by A.6,
where relevant.
On Tue, Nov 23, 2021 at 09:53:50AM +0200, Wouter Verhelst wrote:
Text of the GR
==============
The Debian Developers, by way of General Resolution, amend the Debian constitution under point 4.1.2 as follows. This General Resolution requires a 3:1 majority.
Sections 4 through 7
--------------------
Copy from Russ' proposal, replacing cross-references to A.5 by A.6, where relevant.
Since this is based on Russ' proposal, and that has been changed, I
would like you to confirm that it's based on it's current proposal
and not the original one.
On Mon, Nov 29, 2021 at 09:31:42AM -0800, Russ Allbery wrote:
Wouter Verhelst <w@uter.be> writes:
.... aaand this should've been signed. Good morning.
On Tue, Nov 23, 2021 at 09:50:14AM +0200, Wouter Verhelst wrote:
All this changes my proposal to the below. I would appreciate if my
seconders would re-affirm that they agree with the changes I propose,
and apologies for the mess.
I think this is at or near the required number of sponsors
I think that's the case too, but didn't have time to properly verify it.
That will probably be something for tomorrow.
On Mon, Nov 29, 2021 at 06:52:59PM +0100, Kurt Roeckx wrote:
On Mon, Nov 29, 2021 at 09:31:42AM -0800, Russ Allbery wrote:
Wouter Verhelst <w@uter.be> writes:
.... aaand this should've been signed. Good morning.
On Tue, Nov 23, 2021 at 09:50:14AM +0200, Wouter Verhelst wrote:
All this changes my proposal to the below. I would appreciate if my
seconders would re-affirm that they agree with the changes I propose, >> and apologies for the mess.
I think this is at or near the required number of sponsors
I think that's the case too, but didn't have time to properly verify it. That will probably be something for tomorrow.
Ping?
According to my count, we're now at six sponsors: Holger,
Pierre-Elliott, Mathias, Kyle, Mattia, Louis-Philippe. That's one over,
isn't it?
On Thu, Dec 02, 2021 at 03:50:22PM +0200, Wouter Verhelst wrote:
Ping?
I've pushed this to the website on Tuesday. I forgot to mail
that I've done so.
"Wouter" == Wouter Verhelst <w@uter.be> writes:
"Wouter" == Wouter Verhelst <w@uter.be> 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?
On Thu, Dec 02, 2021 at 01:46:51PM -0700, Sam Hartman wrote:
"Wouter" == Wouter Verhelst <w@uter.be> 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:-)
Heh :)
I first wanted to know whether other people think my reading makes
sense, or if I'm just overthinking it...
Thanks for noticing this.
I'll take it you think I'm not overthinking things then.
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?
I could bypass the whole thing and claim a minor change. That's probably cheating, but then again, it is what I had always intended, so from that
POV I guess it isn't.
So unless someone objects, the below is now the proposal:
Rationale
=========
Much of the rationale of Russ' proposal still applies, and indeed this amendment builds on it. However, the way the timing works is different,
on purpose.
Our voting system, which neither proposal modifies, as a condorcet
voting mechanism, does not suffer directly from too many options on the ballot. While it is desirable to make sure the number of options on the ballot is not extremely high for reasons of practicality and voter
fatigue, it is nonetheless of crucial importance that all the *relevant* options are represented on the ballot, so that the vote outcome is not questioned for the mere fact that a particular option was not
represented on the ballot. Making this possible requires that there is sufficient time to discuss all relevant opinions.
Russ' proposal introduces a hard limit of 3 weeks to any and all ballot processes, assuming that that will almost always be enough, and relying
on withdrawing and restarting the voting process in extreme cases where
it turns out more time is needed; in Russ' proposal, doing so would
increase the discussion time by another two weeks at least (or one if
the DPL reduces the discussion time).
In controversial votes, I believe it is least likely for all ballot
proposers to be willing to use this escape hatch of withdrawing the vote
and restarting the process; and at the same time, controversial votes
are the most likely to need a lot of discussion to build a correct
ballot, which implies they would be most likely to need some extra time
-- though not necessarily two more weeks -- for the ballot to be
complete.
At the same time, I am not insensitive to arguments of predictability, diminishing returns, and process abuse which seem to be the main
arguments in favour of a hard time limit at three weeks.
For this reason, my proposal does not introduce a hard limit, and
*always* makes it theoretically possible to increase the discussion
time, but does so in a way that extending the discussion time becomes
harder and harder as time goes on. I believe it is better for the constitution to allow a group of people to have a short amount of extra
time so they can finish their proposed ballot option, than to require
the full discussion period to be restarted through the withdrawal and
restart escape hatch. At the same time, this escape hatch is not
removed, although I expect it to be less likely to be used.
The proposed mechanism sets the initial discussion time to 1 week, but
allows it to be extended reasonably easily to 2 or 3 weeks, makes it
somewhat harder to reach 4 weeks, and makes it highly unlikely (but
still possible) to go beyond that.
Text of the GR
==============
The Debian Developers, by way of General Resolution, amend the Debian constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Sections 4 through 7
--------------------
Copy from Russ' proposal, replacing cross-references to A.5 by A.6,
where relevant.
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Replace the sentence "The minimum discussion period is 2 weeks."
by "The initial discussion period is 1 week." Strike the sentence
"The maximum discussion period is 3 weeks".
A.1.4. Strike in its entirety
A.1.5. Rename to A.1.4, and strike the sentence "In this case the length
of the discussion period is not changed".
A.1.6. Strike in its entirety
A.1.7. Rename to A.1.5.
After A.2, insert:
A.3. Extending the discussion time.
1. When less than 48 hours remain in the discussion time, any Developer
may propose an extension to the discussion time, subject to the
limitations of A.3.3. These extensions may be sponsored according to
the same rules that apply to new ballot options.
2. As soon as a time extension has received the required number of
sponsors, these sponsorships are locked in and cannot be withdrawn,
and the time extension is active.
3. When a time extension has received the required number of sponsors,
its proposers and sponsors may no longer propose or sponsor any
further time extension for the same ballot, and any further sponsors
for the same extension proposal will be ignored for the purpose of
this paragraph. In case of doubt, the Project Secretary decides how
the order of sponsorships is determined.
4. The first two successful time extensions will extend the discussion
time by one week; any further time extensions will extend the
discussion time by 72 hours.
5. Once the discussion time is longer than 4 weeks, any Developer may
object to further time extensions. Developers who have previously
proposed or sponsored a time extension may object as well. If the
number of objections outnumber the proposer and their sponsors,
including sponsors who will be ignored as per A.3.3, the time
extension will not be active and the discussion time does not change.
6. Once the discussion time expires, any pending time extension
proposals that have not yet received their required number of
sponsors are null and void, and no further time extensions may be
proposed.
A.3. Rename to A.4.
A.3.6 (now A.4.6): replace 'A.3.4' by 'A.4.4'.
A.4. Rename to A.5.
A.4.2 (now A.5.2): replace 'A.5' by 'A.6'.
A.5. Rename (back) to A.6.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I could bypass the whole thing and claim a minor change. That's probably cheating, but then again, it is what I had always intended, so from that
POV I guess it isn't.
So unless someone objects, the below is now the proposal:
Rationale
=========
Much of the rationale of Russ' proposal still applies, and indeed this amendment builds on it. However, the way the timing works is different,
on purpose.
Our voting system, which neither proposal modifies, as a condorcet
voting mechanism, does not suffer directly from too many options on the ballot. While it is desirable to make sure the number of options on the ballot is not extremely high for reasons of practicality and voter
fatigue, it is nonetheless of crucial importance that all the *relevant* options are represented on the ballot, so that the vote outcome is not questioned for the mere fact that a particular option was not
represented on the ballot. Making this possible requires that there is sufficient time to discuss all relevant opinions.
Russ' proposal introduces a hard limit of 3 weeks to any and all ballot processes, assuming that that will almost always be enough, and relying
on withdrawing and restarting the voting process in extreme cases where
it turns out more time is needed; in Russ' proposal, doing so would
increase the discussion time by another two weeks at least (or one if
the DPL reduces the discussion time).
In controversial votes, I believe it is least likely for all ballot
proposers to be willing to use this escape hatch of withdrawing the vote
and restarting the process; and at the same time, controversial votes
are the most likely to need a lot of discussion to build a correct
ballot, which implies they would be most likely to need some extra time
-- though not necessarily two more weeks -- for the ballot to be
complete.
At the same time, I am not insensitive to arguments of predictability, diminishing returns, and process abuse which seem to be the main
arguments in favour of a hard time limit at three weeks.
For this reason, my proposal does not introduce a hard limit, and
*always* makes it theoretically possible to increase the discussion
time, but does so in a way that extending the discussion time becomes
harder and harder as time goes on. I believe it is better for the constitution to allow a group of people to have a short amount of extra
time so they can finish their proposed ballot option, than to require
the full discussion period to be restarted through the withdrawal and
restart escape hatch. At the same time, this escape hatch is not
removed, although I expect it to be less likely to be used.
The proposed mechanism sets the initial discussion time to 1 week, but
allows it to be extended reasonably easily to 2 or 3 weeks, makes it
somewhat harder to reach 4 weeks, and makes it highly unlikely (but
still possible) to go beyond that.
Text of the GR
==============
The Debian Developers, by way of General Resolution, amend the Debian constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Sections 4 through 7
--------------------
Copy from Russ' proposal, replacing cross-references to §A.5 by §A.6,
where relevant.
Section A
---------
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Replace the sentence "The minimum discussion period is 2 weeks."
by "The initial discussion period is 1 week." Strike the sentence
"The maximum discussion period is 3 weeks".
A.1.4. Strike in its entirety
A.1.5. Rename to A.1.4, and strike the sentence "In this case the length
of the discussion period is not changed".
A.1.6. Strike in its entirety
A.1.7. Rename to A.1.5.
After A.2, insert:
A.3. Extending the discussion time.
1. When less than 48 hours remain in the discussion time, any Developer
may propose an extension to the discussion time, subject to the
limitations of §A.3.3. These extensions may be sponsored according to
the same rules that apply to new ballot options.
2. As soon as a time extension has received the required number of
sponsors, these sponsorships are locked in and cannot be withdrawn,
and the time extension is active.
3. When a time extension has received the required number of sponsors,
its proposers and sponsors may no longer propose or sponsor any
further time extension for the same ballot, and any further sponsors
for the same extension proposal will be ignored for the purpose of
this paragraph. In case of doubt, the Project Secretary decides how
the order of sponsorships is determined.
4. The first two successful time extensions will extend the discussion
time by one week; any further time extensions will extend the
discussion time by 72 hours.
5. Once the discussion time is longer than 4 weeks, any Developer may
object to further time extensions. Developers who have previously
proposed or sponsored a time extension may object as well. If the
number of objections outnumber the proposer and their sponsors,
including sponsors who will be ignored as per §A.3.3, the time
extension will not be active and the discussion time does not change.
6. Once the discussion time expires, any pending time extension
proposals that have not yet received their required number of
sponsors are null and void, and no further time extensions may be
proposed.
A.3. Rename to A.4.
A.3.6 (now A.4.6): replace 'A.3.4' by 'A.4.4'.
A.4. Rename to A.5.
A.4.2 (now A.5.2): replace '§A.5' by '§A.6'.
A.5. Rename (back) to A.6.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 486 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 139:45:43 |
| Calls: | 9,657 |
| Calls today: | 5 |
| Files: | 13,708 |
| Messages: | 6,167,333 |