Re: GR: Change the resolution process (corrected)

[Russ Allbery]

Wouter Verhelst  writes:

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

The current constitution is kind of weird about who gets to make minor
changes and changes to amendments (that's one of the things these
proposals is intended to fix).  So just for procedural completeness, as
the original proposer of the resolution, I propose that Wouter's amendment
be changed to the following new text from Wouter.

I think that satisfies A.1.5.

(There may need to be another revision once I finish my revision of the
base resolution.)

> 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 

Re: GR: Change the resolution process (corrected)

[Wouter Verhelst]

... let's try that with cryptography this time around.

On Thu, Dec 02, 2021 at 11:58:21PM +0200, Wouter Verhelst wrote:
> On Thu, Dec 02, 2021 at 01:46:51PM -0700, Sam Hartman wrote:
> > > "Wouter" == Wouter Verhelst  writes:
> > 
> > Wouter> Hi Kurt,
> > Wouter> On Thu, Dec 02, 2021 at 06:45:24PM +0100, Kurt Roeckx wrote:
> > Wouter> It was always my intent that the discussion time can be kept
> > Wouter> alive as long as it has not yet expired, but that it cannot
> > Wouter> be revived once it has expired. But I now think it does not
> > Wouter> forbid someone from sponsoring an extension proposal when
> > Wouter> the discussion time has already expired.
> > 
> > Wouter> So I think I should add the following to my A.3:
> > 
> > Wouter> 6. Once the discussion time expires, any pending time
> > Wouter> extension proposals that have not yet received their
> > Wouter> required number of sponsors are null and void, and no
> > Wouter> further time extensions may be proposed.
> > 
> > Wouter> Or is that superfluous?
> > 
> > Please say one way or the other so we don't fight about it later:-)
> 
> 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' 

Re: GR: Change the resolution process (corrected)

[Wouter Verhelst]

On Thu, Dec 02, 2021 at 01:46:51PM -0700, Sam Hartman wrote:
> > "Wouter" == Wouter Verhelst  writes:
> 
> Wouter> Hi Kurt,
> Wouter> On Thu, Dec 02, 2021 at 06:45:24PM +0100, Kurt Roeckx wrote:
> Wouter> It was always my intent that the discussion time can be kept
> Wouter> alive as long as it has not yet expired, but that it cannot
> Wouter> be revived once it has expired. But I now think it does not
> Wouter> forbid someone from sponsoring an extension proposal when
> Wouter> the discussion time has already expired.
> 
> Wouter> So I think I should add the following to my A.3:
> 
> Wouter> 6. Once the discussion time expires, any pending time
> Wouter> extension proposals that have not yet received their
> Wouter> required number of sponsors are null and void, and no
> Wouter> further time extensions may be proposed.
> 
> Wouter> Or is that superfluous?
> 
> Please say one way or the other so we don't fight about it later:-)

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
 

Re: GR: Change the resolution process (corrected)

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:

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

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

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

Wouter> Or is that superfluous?

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

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


signature.asc
Description: PGP signature

Re: GR: Change the resolution process (corrected)

[Wouter Verhelst]

Hi Kurt,

On Thu, Dec 02, 2021 at 06:45:24PM +0100, Kurt Roeckx wrote:
> 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.

Ah, yes; indeed. I missed that, obviously.

Looking it over one more time, I noticed a defect.

It was always my intent that the discussion time can be kept alive as
long as it has not yet expired, but that it cannot be revived once it
has expired. But I now think it does not forbid someone from sponsoring
an extension proposal when the discussion time has already expired.

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

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.

Or is that superfluous?

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

Re: GR: Change the resolution process (corrected)

[Kurt Roeckx]

On Thu, Dec 02, 2021 at 03:50:22PM +0200, Wouter Verhelst wrote:
> 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  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?

I've pushed this to the website on Tuesday. I forgot to mail
that I've done so.


Kurt

Re: GR: Change the resolution process (corrected)

[Wouter Verhelst]

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

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

Re: GR: Change the resolution process (corrected)

[Wouter Verhelst]

Hi Kurt,

On Tue, Nov 30, 2021 at 11:54:57PM +0100, Kurt Roeckx wrote:
> 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.

Confirmed. I substantially agree with most of Russ' proposal (and even
contributed to it before the public discussion on this list), just not the
timing.

If Russ changes something that I disagree with, I'll change my proposal
to revert that change, but I don't foresee this happening.

Thanks for checking.

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


signature.asc
Description: PGP signature

Re: GR: Change the resolution process (corrected)

[Kurt Roeckx]

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.


Kurt

Re: GR: Change the resolution process (corrected)

[Kurt Roeckx]

On Mon, Nov 29, 2021 at 09:31:42AM -0800, Russ Allbery wrote:
> Wouter Verhelst  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.


Kurt

Re: GR: Change the resolution process (corrected)

[Russ Allbery]

Wouter Verhelst  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, so for the
sake of formal process clarity, I do not accept this amendment, which
means that it will be listed as a separate ballot option on the eventual
ballot.

Thank you, Wouter, for proposing this!  Happy to let the project decide
which timing approach we collectively prefer.

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

Re: GR: Change the resolution process (corrected)

[Louis-Philippe Véronneau]

On 2021-11-23 02 h 50, 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 

Re: GR: Change the resolution process (corrected)

[Mattia Rizzolo]

I second the below amendament.

On Tue, Nov 23, 2021 at 09:53:50AM +0200, Wouter Verhelst wrote:
> 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 

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 (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 (corrected)

[Russ Allbery]

Simon McVittie  writes:

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

Okay, sounds good.  That's multiple people in support and no one saying
they want to keep it the way I had it, so let's make the change.

I have read the current process *yet again*, and have once again changed
my mind about how this works.  It looks like I can propose a formal
amendment to my own GR since I'm the original proposer (under A.1.1) and
then accept it (under A.1.2).

So, I propose and accept the following amendment:

Change "Further discussion" to "None of the above" in 6.3.1.1 and in
6.3.2.

I will shortly post a new revision of my GR with the minor typo changes
previously discussed and that change.  I didn't get to webwml PRs today
but will try to get to that soon.

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


signature.asc
Description: PGP signature

Re: GR: Change the resolution process (corrected)

[Simon McVittie]

I've lost track of who wrote:
> > > Suggest making this "None of the above" instead of "Further discussion"
> > > to avoid two different default options for TC decisions vs project
> > > decisions.

On Thu, 25 Nov 2021 at 10:28:55 -0600, Gunnar Wolf wrote:
>   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).

When we're voting for a DPL, the default is already NOTA, which we've
always interpreted to mean the same thing as "re-open nominations"
(RON) in some other organizations' systems for electing officers:
constitutionally, we need a DPL, so NOTA winning the DPL election would
mean we need to find a different candidate who enough people can agree on
(and the way we would achieve that is by reopening nominations and hoping
someone more popular will volunteer). I think the equivalence between NOTA
and RON has always been uncontroversial. The only reason we don't have
this for the TC chair is that the TC chair has a fixed set of candidates
(the TC members) so reopening nominations would have no practical effect.

Similarly, when the TC has been asked for a decision, a win for NOTA
would mean none of our draft resolutions were accepted, so the decision
is unresolved and we would need to (loosely) "re-open nominations"
to get a better draft resolution that enough TC members can agree on.

In practice, it seems like NOTA/FD is unlikely to win a TC vote: the
only way I can think of for that to happen is if someone called the vote
prematurely, before we got close enough to consensus to be able to write
at least one option that a majority would vote above NOTA/FD.

If the TC is voting to *not* do something (for example if we have been
asked to overrule the foobar maintainer, but we have consensus that
the foobar maintainer was correct), then it seems we implement that by
voting on the resolution we have consensus for (in this case it would be
"formally decline to overrule foobar maintainer" > FD), rather than
putting up a resolution "overrule the foobar maintainer" that none of us
agree with and then voting FD > "overrule the foobar maintainer".
We could equally well do that by voting
"formally decline to overrule foobar maintainer" > NOTA.

smcv

Re: GR: Change the resolution process (corrected)

[Gunnar Wolf]

Russ Allbery dijo [Sun, Nov 21, 2021 at 03:41:18PM -0800]:
> >>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.


  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.

  Besides, the TC does not only vote when mandated to make a decision;
  we could also host a vote on, say, prospective members to appoint to
  the TC. Take as an example bug #880014 — Had I not been appointed as
  a member, maybe there would be nothing left to discuss. Why mandate
  the then-TC to keep discussing my non-nomination ad nauseam?



signature.asc
Description: PGP signature

Re: GR: Change the resolution process (corrected)

[Wouter Verhelst]

On Tue, Nov 23, 2021 at 09:00:07AM -0800, Russ Allbery wrote:
> Wouter Verhelst  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.

Well, it only took about an hour or so, so I wouldn't say "tons", but yeah :-)

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

Cool.

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

Any and all MRs that reflect what's been discussed/decided on this list
are definitely welcome.

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

Likewise. I wish I could say "but of course, that's how things are
done", except that things do tend to get a bit emotional on this list
sometimes.

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

Yes, thanks; good catch.

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

Yes, indeed; changed as such.

I've made those two changes as a minor change below.

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

No, they should not be ignored for the purpose of point 5.

I'd welcome any suggestions to clarify that wording, if you think that
is necessary.

Speaking of point 5, I've also replaced "outweigh" by "outnumber", which
I think is less awkward.

Updated version:

Rationale
=

Much of the rationale of Russ' proposal still applies, and indeed this

Re: GR: Change the resolution process (corrected)

[Russ Allbery]

Pierre-Elliott Bécue  writes:
> Russ Allbery  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".

Oh, thank you, I did entirely miss that.  Also now cued up.  I'm going to
give it another day for more eyes on the proposal and then will post a
(signed) revised version with minor changes.

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

Re: GR: Change the resolution process (corrected)

[Pierre-Elliott Bécue]

Russ Allbery  wrote on 23/11/2021 at 23:39:51+0100:

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

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

-- 
PEB


signature.asc
Description: PGP signature

Re: GR: Change the resolution process (corrected)

[Russ Allbery]

Kurt Roeckx  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
(adding a missing "is" in A.2.3), which I intend to make as a minor
change.  There was an open question about the default option for the TC,
but I'd like to have people weigh in if they would like that to change.

(I believe that is not a minor change and, since the GR has started,
should be made via amendment if we are going to make it, so it would need
sponsors.)

Once we've sorted out the best place to put it on Salsa, I'll have the
changes in commit form.  It may be useful to link to that from the web
site and/or ballot, but I'm not sure the right procedural way to do that
(or if it should be done).

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

Re: GR: Change the resolution process (corrected)

[Kurt Roeckx]

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.


Kurt

Re: GR: Change the resolution process (corrected)

[Russ Allbery]

Don Armstrong  writes:

> Because of this (and others), can I suggest that the ballot option be
> specified as a wdiff to the existing constitution?

Thanks to Wouter's work, here's a wdiff against the webwml of the current
constitution.  This diff format makes a total hash of 6.3.1 and section A,
so it may be easier to read in the resolution text, but it hopefully makes
clearer the more minor changes made elsewhere.

Pending resolution of the other subthread about this, I will get this all
up on Salsa somewhere and then people can clone the repo with Git or use
the web interface to view the diff in whatever format they find the most
helpful.

diff --git a/english/devel/constitution.wml b/english/devel/constitution.wml
index 3a1247c3037..b87d18db9ca 100644
--- a/english/devel/constitution.wml
+++ b/english/devel/constitution.wml
@@ -234,13 +234,12 @@ earlier can overrule everyone listed later.
  

  
The[-minimum discussion period is 2 weeks, but may be varied by-]
[-up to 1 week by the Project Leader.  The-] Project Leader has a casting 
vote.  There is a quorum of [-3Q.-]{+3Q.+}
{+The default option is "None of the above."+}
  

  
Proposals, sponsors, [-amendments,-]{+ballot options,+} calls for votes 
and other
formal actions are made by announcement on a publicly-readable
electronic mailing list designated by the Project Leader's
Delegate(s); any Developer may post there.
@@ -302,7 +301,10 @@ earlier can overrule everyone listed later.
  

  
Propose[-draft-] General Resolutions and [-amendments.-]{+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.+}
  

  
@@ -378,7 +380,7 @@ earlier can overrule everyone listed later.

  
   The decision will be made using the method specified in section
   [-A.6-]{+A.5+} of the Standard Resolution Procedure.  The 
quorum is the
   same as for a General Resolution (4.2) and the default
   option is None Of The Above.
  
@@ -471,7 +473,11 @@ view when making decisions in their capacity as Leader.
   including themselves; there is no default option. The vote
   finishes when all the members have voted, or when the voting
   period has ended. The result is determined using the method
   specified in [-section A.6-]{+A.5+} of the Standard Resolution 
Procedure.
   {+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.+}
   
  

@@ -548,30 +554,62 @@ view when making decisions in their capacity as 
Leader.


  
[-The Technical Committee uses the Standard Resolution-]
[-Procedure.-]{+Resolution process.+}

[-A draft-]{+The Technical Committee uses the following process to 
prepare a+}
resolution [-or amendment-]{+for vote:+}

{++}
{+  Any member of the Technical Committee+} may [-be proposed by 
any-]{+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.+}

{+  Any+} member of the Technical [-Committee.  There-]{+Committee may 
propose additional+}
{+  ballot options or modify or withdraw a ballot option they+}
{+  proposed.+}

{+  If all ballot options except the default option are withdrawn,+}
{+  the process+} is [-no minimum discussion period;-]{+canceled.+}

{+  Any member of+} the [-voting period lasts-]{+Technical Committee 
may call+} for [-up-]{+a vote on the+}
{+  ballot as it currently stands. This vote begins immediately, but if+}
{+  any other member of the Technical Committee objects+} to [-one week, or 
until-]{+calling for a+}
{+  vote before+} the [-outcome-]{+vote completes, the vote+} is {+canceled 
and has+} no
  [-longer in doubt.  Members may change their votes.  
There-]{+effect.+}

{+  Two weeks after the original proposal the ballot+} is {+closed to+}
{+  any changes and voting starts automatically. This vote cannot be+}
{+  canceled.+}

{+  If+} a [-quorum-]{+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
  [-two.-]{+cancellation. During that 24 hour period, no one may call 
for a+}
{+  vote.+}
{++}
  

  
Details regarding voting

[-The-]{+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+}

Re: GR: Change the resolution process (corrected)

[Russ Allbery]

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

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

Re: GR: Change the resolution process (corrected)

[Russ Allbery]

Holger Levsen  writes:

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

Thank you!

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

Re: GR: Change the resolution process (corrected)

[Holger Levsen]

I second this.

On Tue, Nov 23, 2021 at 09:53:50AM +0200, Wouter Verhelst wrote:
> > 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 

Re: GR: Change the resolution process (corrected)

[Mathias Behrle]

* Wouter Verhelst: " Re: GR: Change the resolution process (corrected)" (Tue,
  23 Nov 2021 09:53:50 +0200):

>  aaand this should've been signed. Good morning.

Applies for me as well...
 

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

Seconded.

-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6


pgpQoYfdQCOs8.pgp
Description: Digitale Signatur von OpenPGP

Re: GR: Change the resolution process (corrected)

[Wouter Verhelst]

 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)

[Wouter Verhelst]

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

[Kurt Roeckx]

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)

[Mathias Behrle]

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

[Pierre-Elliott Bécue]

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)

[Holger Levsen]

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)

[Wouter Verhelst]

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)

[Stefano Zacchiroli]

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)

[Holger Levsen]

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)

[Holger Levsen]

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 

Re: GR: Change the resolution process (corrected)

[Russ Allbery]

Don Armstrong  writes:
> 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.

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.

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

Correct.

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

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

Re: GR: Change the resolution process (corrected)

[Don Armstrong]

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.

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

Same as above.

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

Whoever has to modify the constitution at the end of this vote will
likely appreciate it.


-- 
Don Armstrong  https://www.donarmstrong.com

He was wrong. Nature abhors dimensional abnormalities, and seals them
neatly away so that they don't upset people. Nature, in fact, abhors a
lot of things, including vacuums, ships called the Marie Celeste, and
the chuck keys for electric drills.
 -- Terry Pratchet _Pyramids_ p166

Re: GR: Change the resolution process (corrected)

[Pierre-Elliott Bécue]

Russ Allbery  wrote on 20/11/2021 at 19:04:07+0100:

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

Re: GR: Change the resolution process (corrected)

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

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


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


signature.asc
Description: PGP signature

Re: GR: Change the resolution process (corrected)

[Russ Allbery]

Philip Hands  writes:

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

Sigh, thank you.  I'm changing this to "it is removed from the draft
ballot" (as a minor change under A.1.6), assuming no one objects.

I'll post an updated version with any other similar typo changes that turn
up as more people read it sometime towards the middle of the discussion
period.

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

Re: GR: Change the resolution process (corrected)

[Philip Hands]

Russ Allbery  writes:

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

Seconded.

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'

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: GR: Change the resolution process (corrected)

[Timo Röhling]

* Russ Allbery  [2021-11-20 10:04]:

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. 

GR: Change the resolution process (corrected)

[Russ Allbery]

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