Re: Diffs for GR: Change the resolution process

[Jonathan Carter]

On 2021/11/27 03:34, Russ Allbery wrote:

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


Thank you! I've been meaning to do this for a while!

-Jonathan

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

[Kurt Roeckx]

On Fri, Nov 26, 2021 at 08:19:26AM -0800, Russ Allbery wrote:
> Timo Röhling  writes:
> 
> > I was under the impression that this amendment by the original
> > proposer does not require re-sponsoring, and my consent is
> > implicitly assumed unless I choose to object. Am I wrong?
> 
> > (If I am, consider this my sponsoring of the amended version)
> 
> That's also my understanding; I don't think anyone else has to do anything
> unless they object.  (But of course Kurt's ruling is the one to follow.)

I agree with that.


Kurt

Diffs for GR: Change the resolution process

[Russ Allbery]

Bill Allombert  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.

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

The implementation of my GR as webwml is now available on the branch
gr-2021-003 on rra/webwml on Salsa.  Here is the file itself:

https://salsa.debian.org/rra/webwml/-/blob/gr-2021-003/english/devel/constitution.wml

If you download and rename that file to have a .html extension, w3m or
other HTML renderers seem to do a decent job.

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

You can also clone the repository with:

git clone https://salsa.debian.org/rra/webwml.git

and then compare the master branch with the gr-2021-003 branch via
whatever mechanism you prefer (such as git diff --color-words).

I've also sent a PR to Wouter's repository to update the constitution-russ
branch with the same changes, and will be sending a PR to merge those
changes (where relevant) into his branch if he wants.

(Please let me know if anyone sees any inconsistencies between this and
what I formally proposed.)

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


signature.asc
Description: PGP signature

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

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

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

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


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Russ Allbery dijo [Fri, Nov 26, 2021 at 08:19:26AM -0800]:
> > I was under the impression that this amendment by the original
> > proposer does not require re-sponsoring, and my consent is
> > implicitly assumed unless I choose to object. Am I wrong?
> 
> > (If I am, consider this my sponsoring of the amended version)
> 
> That's also my understanding; I don't think anyone else has to do anything
> unless they object.  (But of course Kurt's ruling is the one to follow.)

Ok... Well, your new text has at least three full-text seconders and
one implicit seconder (who didn't full-quote it). It won't hurt if
people sign it ;-)

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

[Gunnar Wolf]

Thanks, Russ.

Seconded.

Russ Allbery dijo [Thu, Nov 25, 2021 at 07:25:45PM -0800]:
> Here is an updated version of my proposal, which incorporates the formal
> amendment to change the default option for TC resolutions to also be "None
> of the above" and fixes two typos.
> 
> 
> 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 "None of the above". 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 

Re: GR: Change the resolution process (corrected)

[Russ Allbery]

Bill Allombert  writes:

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

Yes, absolutely.  Hopefully should be available by the end of the day via
Salsa's repository and also as a Git repository people can clone and then
diff with whatever flags and tools they wish.

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

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

[Russ Allbery]

Timo Röhling  writes:

> I was under the impression that this amendment by the original
> proposer does not require re-sponsoring, and my consent is
> implicitly assumed unless I choose to object. Am I wrong?

> (If I am, consider this my sponsoring of the amended version)

That's also my understanding; I don't think anyone else has to do anything
unless they object.  (But of course Kurt's ruling is the one to follow.)

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

Re: GR: Change the resolution process (corrected)

[Bill Allombert]

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.

Hello Russ,

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.

Sorry.
-- 
Bill. 

Imagine a large red swirl here.

Re: GR: Change the resolution process (corrected)

[Kyle Robbertze]

Let's try this signed. Seconded

On 2021/11/26 12:35, Kyle Robbertze wrote:


On 2021/11/23 09:53, Wouter Verhelst wrote:

 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 

Re: GR: Change the resolution process (corrected)

[Kyle Robbertze]

On 2021/11/23 09:53, Wouter Verhelst wrote:

 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. 

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

[Holger Levsen]

I second this.

On Thu, Nov 25, 2021 at 07:25:45PM -0800, Russ Allbery wrote:
> 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 "None of the above". 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 "None of the above".
> 
> 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 

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

[Timo Röhling]

* Pierre-Elliott Bécue  [2021-11-26 09:49]:

Seconded.

I was under the impression that this amendment by the original
proposer does not require re-sponsoring, and my consent is
implicitly assumed unless I choose to object. Am I wrong?

(If I am, consider this my sponsoring of the amended version)


Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

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

[Pierre-Elliott Bécue]

Russ Allbery  wrote on 26/11/2021 at 04:25:45+0100:

> [[PGP Signed Part:No public key for 7D80315C5736DE75 created at 
> 2021-11-26T04:25:45+0100 using RSA]]
> Here is an updated version of my proposal, which incorporates the formal
> amendment to change the default option for TC resolutions to also be "None
> of the above" and fixes two typos.
>
>
> 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 "None of the above". 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