Re: GR: Change the resolution process (corrected)
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
Re: GR: Change the resolution process (corrected)
... 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
Re: GR: Change the resolution process (corrected)
On Tue, Nov 23, 2021 at 12:09:54AM +0100, Mathias Behrle wrote: > > Seconded. Your message isn't signed. Kurt
Re: GR: Change the resolution process (corrected)
* Wouter Verhelst: " Re: GR: Change the resolution process (corrected)" (Mon, 22 Nov 2021 17:15:34 +0200): > 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. -- Mathias Behrle ✧ Debian Developer PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: GR: Change the resolution process (corrected)
Wouter Verhelst wrote on 22/11/2021 at 16:15:34+0100: > [[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
Re: GR: Change the resolution process (corrected)
tl;dr: I second this. On Mon, Nov 22, 2021 at 05:15:34PM +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 > > > 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. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Stop saying that we are all in the same boat. We’re all in the same storm. But we’re not all in the same boat. signature.asc Description: PGP signature
Re: GR: Change the resolution process (corrected)
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.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
signature.asc
Description: PGP signature
Re: GR: Change the resolution process (corrected)
On Sun, Nov 21, 2021 at 03:41:18PM -0800, Russ Allbery wrote: > 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. FWIW, when I produced the various word diffs for for https://www.debian.org/vote/2014/vote_004 IIRC I just started from the textual version of the Constitution in /usr/share/doc/debian/constitution.txt.gz . Feel free to have a look at the Git repo that I used at the time, which is now here: https://gitlab.com/zacchiro/debian-gr-ctte-term-limit There might be some (trivial) tooling that could be reusable for this case (I didn't check). (What you hint at, having a Git repo with both the historical and proposed changes of the Debian constitution would indeed be nice to have, but IMHO it is not a requirement to address the immediate need pointed out by Don, of easing understandability of this GR.) Thanks a lot for your work on this! Cheers -- Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack _. ^ ._ Full professor of Computer Science o o o \/|V|\/ Télécom Paris, Polytechnic Institute of Paris o o o <\> Co-founder & CTO Software Heritageo o o o /\|^|/\ Former Debian Project Leader & OSI Board Director '" V "' signature.asc Description: PGP signature
Re: GR: Change the resolution process (corrected)
On Sun, Nov 21, 2021 at 03:41:18PM -0800, Russ Allbery wrote: > > Because of this (and others), can I suggest that the ballot option be > > specified as a wdiff to the existing constitution? > 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. I *believe* you'll find it in english/devel/constitution.wml in g...@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...) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Change is coming whether you like it or not. signature.asc Description: PGP signature
Re: GR: Change the resolution process (corrected)
tl;dr: I second this. On Sat, Nov 20, 2021 at 10:04:07AM -0800, Russ Allbery wrote: > 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
