Re: Draft GR for resolution process changes

[Felix Lechner]

Hi,

On Thu, Nov 18, 2021 at 11:06 AM Russ Allbery  wrote:
>
> This problem only applies if there are some options requiring a
> supermajority and other options that require a simple majority.

Thanks! I would find it easier if the same threshold to beat FD in a
vote applied uniformly to all responses other than FD.

Kind regards
Felix Lechner

Re: Draft GR for resolution process changes

[Russ Allbery]

Felix Lechner  writes:
> On Thu, Nov 18, 2021 at 9:01 AM Sam Hartman  wrote:

>> we could (and did) say that option [FD] gets dropped.
>> So in the situation above, "The DFSG is great" wins even though more
>> people would have preferred to replace the DFSG than to say it was
>> great.

> Would option (2) win here even if it did not affirm the DFSG but
> instead sought to alter it in a way distinct from option (1)?

No, it wouldn't, since in that case both options would require a 3:1
majority.  This problem only applies if there are some options requiring a
supermajority and other options that require a simple majority.

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

Re: Draft GR for resolution process changes

[Felix Lechner]

Hi,

On Thu, Nov 18, 2021 at 9:01 AM Sam Hartman  wrote:
>
> we could (and did) say that option [FD] gets dropped.
> So in the situation above, "The DFSG is great" wins even though more
> people would have preferred to replace the DFSG than to say it was
> great.

Would option (2) win here even if it did not affirm the DFSG but
instead sought to alter it in a way distinct from option (1)? Thanks!

Kind regards
Felix Lechner

Re: Draft GR for resolution process changes

[Russ Allbery]

Charles Plessy  writes:

> One last question: in some complex GRs there were discussions about
> problems caused by mixing 1:1 and 3:1 majority options, which frankly
> speaking I could not undertand because I never studied our Condorcet
> method in details.  Do you think that such mixes can be problemating and
> does your proposal address that ?

As Sam said, my proposal doesn't address that.  We did talk about trying
to tackle this as well in the run-up to my proposal, but didn't arrive at
any straightforward solutions that seemed clearly better.

With the benefit of this discussion, I'm going to plead out of scope for
that as well, given how complex the proposal has already gotten through
chasing down all the references to the current proposal system.

Sam's explanation is excellent and matches my understanding.

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

Re: Draft GR for resolution process changes

[Sam Hartman]

> "Charles" == Charles Plessy  writes:
Charles> One last question: in some complex GRs there were
Charles> discussions about problems caused by mixing 1:1 and 3:1
Charles> majority options, which frankly speaking I could not
Charles> undertand because I never studied our Condorcet method in
Charles> details.  Do you think that such mixes can be problemating
Charles>

I can explain the issues I see.
Whether they are problematic depends on how you think things ought to
work.

1) Debian prefers an answer to FD.
So, consider the following options:

1) Change the DFSG.
2)  The DFSG is great
3) FD

Option 1 defeats option 2
Option 1 defeats option 3 by say 2.0:1

So, option 1 cannot win because option 1 needs to defeat option 3 by
3:1 to win.

There are two reasonable things we could have said the rules cause to
happen in that case.  First, we could have said that if an option would
have won but for super majority, then inherently FD wins.
Or we could (and did) say that option gets dropped.
So in the situation above, "The DFSG is great" wins even though more
people would have preferred to replace the DFSG than to say it was
great.

I've intentionally phrased things to maximize how bad it sounds.

If we allowed FD to win in this situation, it would be open to strategic
abuse: you could potentially drag out the discussion by  introducing a
supermajority option that you thought would win, but not win enough.

But it also seems like the current system is open to abuse because  of
the situation I described above.
Whether that's true depends on how you think about FD.

Consider another restatement of the results above.

Most people are either okay revising the DFSG or saying the DFSG is
great.
Both options are fine with the project.
More people would prefer to revise the DFSG, but not enough people to
actually permit the change.
We prefer to be done with discussions rather than have them drag out,
and we've encoded that to a certain extent in our constitution.
So, we decided to say the DFSG was great because we could do that today
rather than let things drag out.


2) There's another issue  involving supermajorities.

In a ballot like the one we're about to face, I might have an incentive
to rank an opposing constitutional amendment below FD even though I'd
rather see that amendment succeed than have more discussion.  After all
it might fail its super majority if enough people do that.
Again, whether this is abuse depends a lot on how you think about voter
intent.

The only way to avoid all of these issues is to avoid super majorities
entirely.

We're effectively saying that there are cases where the voters prefer
some option, and we're not going to let the voters choose that option
because they don't prefer it enough.
I think that is going to open up some strategic abuse somewhere.
The question is what sort of abuse do you permit.

Russ's proposal does not make any changes in these areas.
I actually think we have a good set of trade offs already and so I'm
happy with that.
But others might like a different set of trade offs.


signature.asc
Description: PGP signature

Re: Draft GR for resolution process changes

[Sam Hartman]

> "Timo" == Timo Röhling  writes:
Timo> I must say I find your reasoning convincing. A certain
Timo> stability of ballot options is desirable, and as our voting
Timo> scheme does not suffer from spoiler effects, we can afford to
Timo> keep the odd stale option. Besides, as you pointed out, the
Timo> original proposer can always formally withdraw and ask their
Timo> sponsors to do the same; if there is hidden support, it will
Timo> either materialize or the option will be discarded; no
Timo> additional procedural rules required.

I too find the reasoning convincing.


signature.asc
Description: PGP signature

Re: Draft GR for resolution process changes

[Russ Allbery]

Russ Allbery  writes:

> This paragraph helped me realize that you see my proposal as a
> substantive change over the current rules for the original GR proposer.
> I hadn't entirely realized that it was, and I see that I missed some
> subtlety in current rules, so I went back and reviewed them.  I believe
> the implications of the current constitution (which I think was also in
> effect in 2008) are:

> 1. The original proposer of the GR can only change the text themselves if
>all the sponsors agree (A.1.5)

Oh, wait, no, it's even more complicated than that, because I think A.1.5
only applies to the *amendments* and not to the original text.  So I think
you need K+1 people to make any change to the original GR text (other than
A.1.6 minor changes), but the proposer can make changes to the
*amendments* provided that all sponsors agree.

Each time I think I understand the current constitutional rules, I realize
that I missed something.

(I think the rest of the analysis still holds, although my change is more
complicated than making point 1 apply to all ballot options.)

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

Re: Draft GR for resolution process changes

[Russ Allbery]

Charles Plessy  writes:

> here are comments from my point of view in the hope of being useful,
> please do not take them as objections; I know that you have looked at
> the problem through many more angles than I did.  By the way, sorry in
> advance if what I write today has been already addressed by others
> earlier.

Oh, no, this is very helpful, and don't worry, you're not repeating
anything other folks have said.

> Le Thu, Nov 11, 2021 at 08:26:00AM -0800, Russ Allbery a écrit :
>> Once a proposal has been sponsored and added to the ballot, we, as a
>> general social convention, stop sponsoring it unless it feels
>> particularly important to be listed as a sponsor.

> This practice of sponsoring over the necessary number has always made me
> uncomfortable.  The more we give importance to the question of who
> sponsored, the more we put social pressure on the voters.  This is
> another reason why I think that limiting strictly to 5 would be better.
> This said, anonymous voting (which I think is better to decide in a
> separate GR) would solve that problem entirely.

I think this matches my opinion as well.

We do have a reasonably strong social convention to not pile on
sponsorships, which has been sufficient in recent GRs to keep the number
of sponsors at 15 or less.  Which is still a lot more than 5, but which is
still quite small compared to the total number of people who vote.

>> In other words, I think once a ballot option makes it onto the ballot,
>> the rules are attempting to capture the sense that it no longer belongs
>> just to its proposer, but now represents some unknown number of people
>> who want to vote for it.

> My conclusion with the 2008 GR is that removing the original option made
> it a better GR.  The removal triggered the addition of new options, but
> none of them were identical to the original one.  Perhaps it would have
> happened also even if sponsors had a veto, but I believe that personal
> responsibility is going to be more efficient than collective
> intelligence there.

This paragraph helped me realize that you see my proposal as a substantive
change over the current rules for the original GR proposer.  I hadn't
entirely realized that it was, and I see that I missed some subtlety in
current rules, so I went back and reviewed them.  I believe the
implications of the current constitution (which I think was also in effect
in 2008) are:

1. The original proposer of the GR can only change the text themselves if
   all the sponsors agree (A.1.5)

2. Someone else can propose a formal amendment to the text of the
   resolution by getting the normal number of sponsors, in which case the
   original proposer of the GR can accept it without needing the approval
   of any other sponsors and it replaces the original text (A.1.1 and
   A.1.2)

3. A formal amendment can be rejected by the original proposer of the GR,
   at which point it becomes a new ballot option.  At that point, only the
   original proposer of the GR can suggest changes to the unaccepted
   amendment, and all sponsors of the unaccepted amendment have to agree
   for the change to be made (A.1.5).  Otherwise, unaccepted amendments
   can't be changed at all, but can be withdrawn (A.4).

The part that I was focused on fixing was the last part, which treats
"unaccepted amendments" (the current term for ballot options) in a rather
weird way and gives the original GR proposer the sole power to modify them
even though, in practice, those amendments are often contrary to the
opinion of the original GR proposer.  My intent was to make the rules in
situation 1 apply to situation 3 and also get rid of this special and
somewhat odd grant of powers to the original proposer.

I think what you're pointing out is that 2 also changes in my proposal,
which I hadn't paid close attention to.  Currently, if a change to the
original GR (but not any of the unaccepted amendments) has the support of
K+1 people (the proposer of the amendment plus the sponsors), the original
proposer of the GR can choose to replace their text with the amended text
without having to get the approval of the existing sponsors.  Under my
proposal, this concept of a sponsored amendment doesn't exist; if someone
wants to change a ballot option rather than add a new one, they have to
convince the proposer of that ballot option and all of its sponsors.

I agree that this is a change; I'm eliminating the whole idea of an
accepted amendment and relying on only the first point.  But I think it's
a relatively minor change that leads to a lot of process simplification
but not much difference in the outcome.

Under my proposed system, if there is K+1 support for a new form of a
ballot option, the original proposer agrees, but one of the original
sponsors disagrees, the (slightly more complex in this edge case) process
is:

1. The new ballot option is proposed and sponsored as normal.  The
   original GR proposer can sponsor that new ballot option.  It is added
   to 

Re: Draft GR for resolution process changes

[Charles Plessy]

Thanks Russ for keeping me in the loop,

here are comments from my point of view in the hope of being useful,
please do not take them as objections; I know that you have looked at
the problem through many more angles than I did.  By the way, sorry
in advance if what I write today has been already addressed by others
earlier.

Le Thu, Nov 11, 2021 at 08:26:00AM -0800, Russ Allbery a écrit :
> 
> Once a proposal has been sponsored and added to the ballot, we, as a
> general social convention, stop sponsoring it unless it feels particularly
> important to be listed as a sponsor.

This practice of sponsoring over the necessary number has always made me
uncomfortable.  The more we give importance to the question of who
sponsored, the more we put social pressure on the voters.  This is
another reason why I think that limiting strictly to 5 would be better.
This said, anonymous voting (which I think is better to decide in a
separate GR) would solve that problem entirely.

> In other words, I think once a ballot option makes it onto the ballot, the
> rules are attempting to capture the sense that it no longer belongs just
> to its proposer, but now represents some unknown number of people who want
> to vote for it.

My conclusion with the 2008 GR is that removing the original option made
it a better GR.  The removal triggered the addition of new options, but
none of them were identical to the original one.  Perhaps it would have
happened also even if sponsors had a veto, but I believe that personal
responsibility is going to be more efficient than collective
intelligence there.

> Once people who have sponsored the original ballot option start
> objecting, I think we should take that as concrete evidence that the
> new option is sufficiently different that it may not represent the
> people who were supporting the old option, and we should therefore
> default to adding the new option via the normal mechanism.

Fraknly speaking, I worry that some day somebody will sponsor as many
options as possible and object to changes for the sake of adding
toxicity to GR.  The more members we have, the less unlikely it becomes.

But even assuming good will, I think that a process that makes it easier
to remove or merge options would serve us better than a process that
makes it easier to fork options.  A lot of GR voters do not follow the
debates on debian-vote, and with too many options, possibly all written
in different styles, there is an increased risk of voting for the
contrary of what we want.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: Draft GR for resolution process changes

[Timo Röhling]

* Russ Allbery  [2021-11-11 08:26]:

Once a proposal has been sponsored and added to the ballot, we, as a
general social convention, stop sponsoring it unless it feels particularly
important to be listed as a sponsor.  That means that any given option
currently on the ballot usually has "hidden" support in the form of
Developers who intend to vote for it but haven't sponsored it.  It seems
likely that in some situations those Developers may think "okay, the
opinion I really cared about is on the ballot so I can vote the way I
want" and then may tune out the subsequent discussion.

In other words, I think once a ballot option makes it onto the ballot, the
rules are attempting to capture the sense that it no longer belongs just
to its proposer, but now represents some unknown number of people who want
to vote for it.

Given that, if the proposer changes their mind and wants to propose a
substantially different ballot option, I think the default should be that
the proposer do that as a separate ballot option and get sponsors for that
new ballot option (and possibly withdraw as the proposer for the original
ballot option).  This reflects the fact that just because the proposer
changed their mind, that doesn't mean that other supporters of that ballot
option also changed their minds.

As Sam says, the ability to make substantive changes if all sponsors agree
is essentially an optimization.  It's tedious to propose a new option,
have everyone sponsor it again, withdraw as proposer of the old option,
and confirm that no one else is stepping forward, so for changes that
everyone agrees make the ballot option better, we should have a way to
allow those to be made more easily.  But we want some sort of check that
this is really true and not just take the proposer's word for it, so we in
essence draft the sponsors of the ballot option as referees to decide
whether this change does make sense in the context in which they
originally supported that option.

I must say I find your reasoning convincing. A certain stability of
ballot options is desirable, and as our voting scheme does not
suffer from spoiler effects, we can afford to keep the odd stale
option. Besides, as you pointed out, the original proposer can
always formally withdraw and ask their sponsors to do the same; if
there is hidden support, it will either materialize or the option
will be discarded; no additional procedural rules required.


Cheers
Timo

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


signature.asc
Description: PGP signature

Re: Draft GR for resolution process changes

[Russ Allbery]

(cc'ing Charles since I'm not sure if he's reading all of debian-vote; let
me know if this is annoying and I should stop.)

Sam Hartman  writes:

> It sounds like what russ and Charles are talking about is the following:

> * You as a proposer want to accept an amendment

> * A sponsor objects, and so you can't even though you would have been
>   able to if you had fewer sponsors.

> I have an alternate proposed fix:

> If the proposer accepts the amendment and there are k sponsors who have
> not objected, the amendment is accepted.
> (I think it's okay even if we end up counting new sponsors to get to k
> who have not objected)

This and Timo Röhling's similar idea were very helpful for thinking
through this.  Thank you!

After pondering this for a couple of days, I'm going to advocate for not
making a change here, even though it looks a bit restrictive.  I think the
key point is this analysis:

> But under Russ's approach, the whole amendment process is really just a
> convenience to make it easier to update an option with less withdrawing
> and re-proposing.

I arrived at a somewhat different conclusion given that point, though,
because I think there's a principle of ballot stability here that's worth
maintaining.  Here's my argument:

Once a proposal has been sponsored and added to the ballot, we, as a
general social convention, stop sponsoring it unless it feels particularly
important to be listed as a sponsor.  That means that any given option
currently on the ballot usually has "hidden" support in the form of
Developers who intend to vote for it but haven't sponsored it.  It seems
likely that in some situations those Developers may think "okay, the
opinion I really cared about is on the ballot so I can vote the way I
want" and then may tune out the subsequent discussion.

In other words, I think once a ballot option makes it onto the ballot, the
rules are attempting to capture the sense that it no longer belongs just
to its proposer, but now represents some unknown number of people who want
to vote for it.

Given that, if the proposer changes their mind and wants to propose a
substantially different ballot option, I think the default should be that
the proposer do that as a separate ballot option and get sponsors for that
new ballot option (and possibly withdraw as the proposer for the original
ballot option).  This reflects the fact that just because the proposer
changed their mind, that doesn't mean that other supporters of that ballot
option also changed their minds.

As Sam says, the ability to make substantive changes if all sponsors agree
is essentially an optimization.  It's tedious to propose a new option,
have everyone sponsor it again, withdraw as proposer of the old option,
and confirm that no one else is stepping forward, so for changes that
everyone agrees make the ballot option better, we should have a way to
allow those to be made more easily.  But we want some sort of check that
this is really true and not just take the proposer's word for it, so we in
essence draft the sponsors of the ballot option as referees to decide
whether this change does make sense in the context in which they
originally supported that option.

Given that, I lean away from setting the bar for modifying a ballot option
the same as the bar for proposing a new option on the grounds that, once
on the ballot, I think options should be stickier than that and the bar
for changing them should be higher.  The sponsors are, in effect,
representing that unknown group of people who were satisfied by that
option and may not be paying attention, so it should be hard to change an
option in a way that may be incompatible with those preferences and, in
the event of any conflict, the default should be to draft a new option.
(But we don't go as far as letting any Developer object, like we do for
the trivial changes provision, because involving people who would never
have voted for the option anyway is less likely to be constructive.)

I believe there is a real bug in the existing constitution in that it at
least implies that someone could sponsor a ballot option solely to then
object to a proposed change to it, which I don't think we want.  I mostly
fixed that bug by requiring people have already sponsored the option
before the change was proposed if they want to object.  But after thinking
about this some more, I don't think we want to go farther.  Once people
who have sponsored the original ballot option start objecting, I think we
should take that as concrete evidence that the new option is sufficiently
different that it may not represent the people who were supporting the old
option, and we should therefore default to adding the new option via the
normal mechanism.

Does that make sense to everyone?

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

Re: Draft GR for resolution process changes

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Sam Hartman  writes:
Charles> - About the sponsors, if there are too many, then the
Charles> proposer is more at risk to face vetos when accepting
Charles> amendments.  (I write that as I accepted major changes as
Charles> the proposer of a GR option some years ago.)  Would it make
Charles> sense to limit the total number of sponsors, and to only
Charles> allow developers to sponsor one option ?

>> I don't understand this concern very well.  If some of your
>> sponsors don't like an amendment you accepted you can withdraw.
>> So long as you have k sponsors remaining, the option can stay on
>> the ballot.

>> What am I missing that leads to your concern?

It sounds like what russ and Charles are talking about is the following:

* You as a proposer want to accept an amendment

* A sponsor objects, and so you can't even though you would have been
  able to if you had fewer sponsors.

I have an alternate proposed fix:

If the proposer accepts the amendment and there are k sponsors who have
not objected, the amendment is accepted.
(I think it's okay even if we end up counting new sponsors to get to k
who have not objected)


Obviously sponsors who don't like the amendment can go off and propose
their own ballot options.

My rationale is that we'd rather not have things be dependent on
strategic ordering of who gets accepted as a sponsor etc.


In the current constitution, the proposer of the resolution is all sorts
of special, and has special powers and so we want to carefully control
what amendments they can accept.

But under Russ's approach, the whole amendment process is really just a
convenience to make it easier to update an option with less withdrawing
and  re-proposing.
I think we want to let proposers change their text provided they have
enough support at the end of the day, so let's effectively say that.

I am sympathetic to the desire to avoid having seconds/sponsorships pile
on.
And yet, I'd prefer not to have a hard limit.
I know I've found myself in cases where it was quite important to me to
be seen as expressing strong support for an option in a situation where
for example I'd been involved in helping draft the option.
And yet I wasn't faste enough on the email.
I think the same has happened to others.
So, I definitely  support social conventions to limit number of
sponsors, but I'd prefer not to have a hard and fast constitutional
rule.


signature.asc
Description: PGP signature

Re: Draft GR for resolution process changes

[Timo Röhling]

* Russ Allbery  [2021-11-08 08:18]:

Probably the simplest fix would be to add something like this as a new
point A.0.3.  Do people think it would be worth adding something like
this?

   If a proposal (or ballot option; see section §A.1) requires some
   number of sponsors N, only the first N Developers indicating they
   sponsor the proposal become sponsors for the purposes of the
   subsequent process. Further sponsorships are not counted. Similarly,
   if more sponsors are needed (such as in cases of withdrawal; see
   section §A.2), only the number of Developers required to meet the
   minimum number of sponsors are added as sponsors. The Project
   Secretary determines the order in which sponsors indicate support.

(I'm really not happy with the wording of that, and am finding it
difficult to word clearly for some reason.  Suggestions welcome, if folks
think this is something the proposal should try to address.)

Given that any Developer can propose a new ballot option anyway, it
feels overly restrictive that a single dissenting voice can block
amendments. Instead, I'd like to treat this more like a fork; anyone
objecting to a change is free to introduce the original version as
their own ballot option, subject to the usual sponsorship
requirements. In practise, this should work like this:

1. The proposer amends their ballot option.

2. If no sponsor objects to the change, we are done.
   Otherwise, continue.

3. If someone objects, the proposer decides if he wants to revert
   the amendment. If yes, we are done. Otherwise, continue.

4. The first objector becomes new proposer for the original
   ballot option, and the original proposer becomes proposer
   for the amended version.

5. Any Developer can sponsor or withdraw from both versions as they
   see fit. By default, i.e. if no other statement is issued, any
   sponsor who objected to the amendment is assumed to have withdrawn
   from the amended version and still sponsoring the old version. All
   other sponsors are assumed to have withdrawn from the old version
   and are sponsoring the amended version.

6. Any version that lacks the required number of sponsors will be
   withdrawn.

Cheers
Timo


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


signature.asc
Description: PGP signature

Re: Draft GR for resolution process changes

[Russ Allbery]

Sam Hartman  writes:

> Charles>  - About the sponsors, if there are too many, then the
> Charles> proposer is more at risk to face vetos when accepting
> Charles> amendments.  (I write that as I accepted major changes as
> Charles> the proposer of a GR option some years ago.)  Would it make
> Charles> sense to limit the total number of sponsors, and to only
> Charles> allow developers to sponsor one option ?

> I don't understand this concern very well.
> If some of your sponsors don't like an amendment you accepted you can
> withdraw.
> So long as you have k sponsors remaining, the option can stay on the
> ballot.

> What am I missing that leads to your concern?

I think it's a little bit inobvious that the correct thing to do in this
case is to withdraw as proposer of the original proposal and then make a
new ballot option proposal and have the non-dissenting sponsors of the
original sponsor that one instead, although I agree that ends up at the
same place.  Hm, and fixing the number of sponsors, while it may make
needing to do that less likely, doesn't remove the chance that one may
need to do that to accept a major amendment.

I was also thinking of the fact that Kurt has had to ask people in the
past to not "pile on" more sponsorships because it makes his tracking for
the web site and similar purposes more tedious, so if we have some other
reason to fix this anyway, it might be worth taking care of that.

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

Re: Draft GR for resolution process changes

[Sam Hartman]

Charles>  - About the sponsors, if there are too many, then the
Charles> proposer is more at risk to face vetos when accepting
Charles> amendments.  (I write that as I accepted major changes as
Charles> the proposer of a GR option some years ago.)  Would it make
Charles> sense to limit the total number of sponsors, and to only
Charles> allow developers to sponsor one option ?

I don't understand this concern very well.
If some of your sponsors don't like an amendment you accepted you can
withdraw.
So long as you have k sponsors remaining, the option can stay on the
ballot.

What am I missing that leads to your concern?

Re: Draft GR for resolution process changes

[Russ Allbery]

Charles Plessy  writes:

> thank you very much for proposing these changes.  Overall they are very
> convincing and would already vote for it today, but there are two things
> that I wonder:

>  - (Not just to you:) Would it be possible to test them in real befoe
>adopting them?  Maybe with some kind of role-playing game where some
>random people are assigned adversarial roles?

I'm quite happy to participate in this, although I don't know how to get
started or how to organize it.  I've mentally run through various
scenarios to try to anticipate them in the draft, but since I wrote it I
have blind spots and I definitely welcome anything that would help us go
over the implications carefully.

>  - About the sponsors, if there are too many, then the proposer is more
>at risk to face vetos when accepting amendments.  (I write that as I
>accepted major changes as the proposer of a GR option some years
>ago.)  Would it make sense to limit the total number of sponsors, and
>to only allow developers to sponsor one option ?

This is a very good point.  Currently, nothing except social convention
prevents people from continuing to sponsor GRs or amendments (ballot
options in the new proposal) after they've already reached the necessary
number of sponsors.  I tried to limit the impact of this a little by
saying that only people who had already sponsored the ballot option at the
time an amendment is proposed can object to it (the current constitution
appears to allow someone to sponsor a GR just to object to an amendment),
but that doesn't entirely fix the issue.

Probably the simplest fix would be to add something like this as a new
point A.0.3.  Do people think it would be worth adding something like
this?

If a proposal (or ballot option; see section §A.1) requires some
number of sponsors N, only the first N Developers indicating they
sponsor the proposal become sponsors for the purposes of the
subsequent process. Further sponsorships are not counted. Similarly,
if more sponsors are needed (such as in cases of withdrawal; see
section §A.2), only the number of Developers required to meet the
minimum number of sponsors are added as sponsors. The Project
Secretary determines the order in which sponsors indicate support.

(I'm really not happy with the wording of that, and am finding it
difficult to word clearly for some reason.  Suggestions welcome, if folks
think this is something the proposal should try to address.)

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

Re: Draft GR for resolution process changes

[Charles Plessy]

Hi Russ,

thank you very much for proposing these changes.  Overall they are very
convincing and would already vote for it today, but there are two things
that I wonder:

 - (Not just to you:) Would it be possible to test them in real befoe
   adopting them?  Maybe with some kind of role-playing game where some
   random people are assigned adversarial roles?

 - About the sponsors, if there are too many, then the proposer is more
   at risk to face vetos when accepting amendments.  (I write that as I
   accepted major changes as the proposer of a GR option some years
   ago.)  Would it make sense to limit the total number of sponsors, and
   to only allow developers to sponsor one option ?

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy