Re: General resolution: Changes to the Standard Resolution Procedure

[Kurt Roeckx]

On Mon, Aug 31, 2015 at 05:01:25PM +0200, Andreas Barth wrote:
> * Didier 'OdyX' Raboud (o...@debian.org) [150831 11:23]:
> > Le lundi, 31 août 2015, 11.04:59 Axel Beckert a écrit :
> 
> > > As far as I understand this would mean proposing an alternative choice
> > > for the voter. In that case, the damage is already done and cannot be
> > > undone. This IMHO only makes sense if I'd propose different
> > > semantics.
> > 
> > The GR proposer can accept formal wording changes directly on his 
> > amendment proposal (§A.1.5).
> > 
> > I think the change would clarify the GR for more voters than only you, 
> > so I'm hereby asking Andreas whether he'd accept a wording change on his 
> > GR proposal as follows (%s/fencepost/off-by-one/g), under §A.1.5:
> > 
> > --- a/vote_002
> > +++ b/vote_002
> > @@ -7,7 +7,7 @@
> >Committee could overrule a Developer with a supermajority of 3:1.
> > 
> >Unfortunately, the definition of supermajorities in the SSD GR has a
> >[-fencepost-]{+off-by-one+} error.  In the new text a supermajority
> >requirement is met only if the ratio of votes in favour to votes
> >against is strictly greater than the supermajority ratio.
> > 
> > @@ -78,9 +78,9 @@
> >votes (whether General Resolutions or votes in the Technical
> >Committee) in progress at the time the change is made.
> > 
> >The effect is to fix the [-fencepost-]{+off-by-one+} bug, and
> >arrange that failing asupermajority voids the whole decision (or
> >makes it advisory), rather than promoting another option.  The
> >[-fencepost-]{+off-by-one+} bugfix will also have a (negligible)
> >effect on any General Resolutions requiring supermajorities.  And
> >after this change the TC chair can choose a non-default option even
> >if it is tied with a default
> 
> Accepted.

I got a bad signature on this message.


Kurt

Re: Strategic Voting Re: General resolution: Changes to the Standard Resolution Procedure

[Sam Hartman]

> "Kurt" == Kurt Roeckx  writes:

Kurt> On Mon, Aug 31, 2015 at 04:49:08PM +0100, Dimitri John Ledkov wrote:

Kurt> One of the problems, and I consider that to be the most
Kurt> important one, is about the stratigic vote that you can do.
Kurt> For example, condiser that there are 2 options (A and B) plus
Kurt> the default option All options are acceptable for everybody,
Kurt> but 75% prefer A and 25% prefer B.  You would except the
Kurt> following vote: 75%: 123 25%: 213

Kurt> Option A would win as expected.

Kurt> If there is a 3:1 majority requirement, you could instead
Kurt> vote: 75%: 123 25%: 312

Kurt> As in, the 2nd group says that option A is not acceptable
Kurt> while in fact it was.

Kurt> This results in the option A being dropped because it does not
Kurt> reach majority.  75% say A acceptable and 25% say it's not
Kurt> resulting in a 3:1 majority saying it's acceptable.  The 75%
Kurt> just don't reach the "strictly greater" than the 3:1 majority
Kurt> requirement.

Kurt> In the end option B wins because of stratigic voting, while if
Kurt> they were honest option A would have won.

So, first, I think we're all agreed that we want to fix the strictly
greater issue.
That is, the example above fails both because you need to be strictly
greater than the majority requirement (equal doesn't count) and because
of the strategic voting.

I'd like to set aside the difference between strictly greater and
greater because that's unlikely to come up in a GR, and because I think
many of us agree we'd like to fix it.

However, I'm skeptical of the strategic voting problem and even more
skeptical of the fix.

What you're saying above is that 25% of the people find option 1
distasteful enough that they are willing to game the system but somehow
they still find option 1 "acceptable."

Assuming we believe that a super majority should apply to this
situation, we believe that enough folks who consider option 1 to be
unacceptable should cause option 1 to lose.

In my mind, distasteful enough to try and game the situation is fairly
good evidence that someone finds an option unacceptable, even if they
wouldn't phrase it that way themselves.

I have been watching how people rank things above and below FD both in
GR elections and in TC votes over the years.  I have not done any
scientific analysis, but I've been amazed at the thought and care people
seem to put into that decision.  And from what I can tell, people seem
to do a good job of thinking of the question as "would I rather get
stuck in another round of discussions than have this option win?"

As an example, the only reason we ever exited the process on init
systems in the TC is that enough TC members felt being done was more
valuable than having their preferred option win.  If you look at the
discussion, you see that people on both sides put a lot of thought into
this.

There's a natural defense to this type of strategic voting that I've
seen us employ.  Have an option similar to option 1 on the ballot that
is a statement of position rather than a constitutional change;
something without a super-majority requirement.
We're fairly good about employing such options on ballots where they
make sense.  For example I'm thinking of the discussions surrounding
amending the DFSG to remove non-free.


Kurt> The solution to this problem is moving the majority check
Kurt> later in the process, so that option B would have been dropped
Kurt> first.  If they did this stratigic voting in that case both
Kurt> options would have been dropped.

So, I think  this opens up far worse problems than it solves.
let's take a specific example.

Let's assume that option 1 is amend the social contract  to remove
non-free.

Option 2 is some statement that discourages non-free, but isn't strong
enough to be a supermajority change.

If option 1 wins but fails majority, w end up with FD winning.

So, then what.  We'd like to have a ballot without option 1 so we can
make progress.  Except now we've created a strategic opportunity for
five developers to put us back into the same position and put option 1
back onto the next ballot.

Forcing ourselves into endless rounds of more discussion on the most
controversial issues is not an improvement.

If we don't make a change, it's important that that we have a
non-supermajority option that is in the same direction as a
super-majority option if there are any options on the ballot that are in
significantly different directions.
That is, a ballot that was remove non-free and FD would be OK, but a
ballot that is remove non-free, reaffirm non-free and FD would be a bad
idea.  Instead you'd want some version of discourage
non-free-but-not-requiring supermajority to be on the second ballot.

In conclusion, endless discussion is not a win.  And I think this
strategic voting fix may bring us there.  If I were to put together an
amendment that fixed 

Re: Strategic Voting Re: General resolution: Changes to the Standard Resolution Procedure

[Kurt Roeckx]

On Thu, Sep 03, 2015 at 02:43:04PM +, Sam Hartman wrote:
> Kurt> The solution to this problem is moving the majority check
> Kurt> later in the process, so that option B would have been dropped
> Kurt> first.  If they did this stratigic voting in that case both
> Kurt> options would have been dropped.
> 
> So, I think  this opens up far worse problems than it solves.
> let's take a specific example.
> 
> Let's assume that option 1 is amend the social contract  to remove
> non-free.
> 
> Option 2 is some statement that discourages non-free, but isn't strong
> enough to be a supermajority change.
> 
> If option 1 wins but fails majority, w end up with FD winning.

This is a very good point, and it currently seems to me that the
current situtation is better than the proposed change.


Kurt

Re: Strategic Voting Re: General resolution: Changes to the Standard Resolution Procedure

[Wouter Verhelst]

On Thu, Sep 03, 2015 at 02:43:04PM +, Sam Hartman wrote:
> In conclusion, endless discussion is not a win.  And I think this
> strategic voting fix may bring us there.  If I were to put together an
> amendment that fixed the strictly greater issue but did not tackle the
> strategic voting issue, would people second?

Absolutely.

Let's not fix issues unless they exist. I don't think the "strategic
voting" issue exists in Debian, and so I don't think we should try to
"fix" it.

I accept that the off-by-one "error" exists for the TC, although I think
the easier fix is to require a 2:1 supermajority for cases where the TC
currently requires a 3:1 supermajority; this would again reduce the
required number of votes to be more in line with what is indeed a more
workable number for the TC, while not changing the semantics for regular
GRs.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


signature.asc
Description: Digital signature

Re: In plain English please?! Re: General resolution: Changes to the Standard Resolution Procedure

[Simon Josefsson]

Kurt Roeckx  writes:

> The solution to this problem is moving the majority check later
> in the process, so that option B would have been dropped first.
> If they did this stratigic voting in that case both options would
> have been dropped.

Interesting -- one thought: haven't voting systems been dissected and
specified in research literature for quite some time?  Isn't there one
that is already established and analyzed that we can refer to, instead
of trying to design these (quite complicated) rules for ourselves?  We
would have to find a voting system that matches Debian's intent, which
might be a challenge though.

/Simon


signature.asc
Description: PGP signature

Re: In plain English please?! Re: General resolution: Changes to the Standard Resolution Procedure

[Kurt Roeckx]

On Tue, Sep 01, 2015 at 09:47:47AM +0200, Simon Josefsson wrote:
> Kurt Roeckx  writes:
> 
> > The solution to this problem is moving the majority check later
> > in the process, so that option B would have been dropped first.
> > If they did this stratigic voting in that case both options would
> > have been dropped.
> 
> Interesting -- one thought: haven't voting systems been dissected and
> specified in research literature for quite some time?  Isn't there one
> that is already established and analyzed that we can refer to, instead
> of trying to design these (quite complicated) rules for ourselves?  We
> would have to find a voting system that matches Debian's intent, which
> might be a challenge though.

As far as I understand the problem is that none of them have a majority
requirement.


Kurt

Re: General resolution: Changes to the Standard Resolution Procedure

[Andreas Barth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Didier 'OdyX' Raboud (o...@debian.org) [150831 11:23]:
> Le lundi, 31 août 2015, 11.04:59 Axel Beckert a écrit :

> > As far as I understand this would mean proposing an alternative choice
> > for the voter. In that case, the damage is already done and cannot be
> > undone. This IMHO only makes sense if I'd propose different
> > semantics.
> 
> The GR proposer can accept formal wording changes directly on his 
> amendment proposal (§A.1.5).
> 
> I think the change would clarify the GR for more voters than only you, 
> so I'm hereby asking Andreas whether he'd accept a wording change on his 
> GR proposal as follows (%s/fencepost/off-by-one/g), under §A.1.5:
> 
> --- a/vote_002
> +++ b/vote_002
> @@ -7,7 +7,7 @@
>Committee could overrule a Developer with a supermajority of 3:1.
> 
>Unfortunately, the definition of supermajorities in the SSD GR has a
>[-fencepost-]{+off-by-one+} error.  In the new text a supermajority
>requirement is met only if the ratio of votes in favour to votes
>against is strictly greater than the supermajority ratio.
> 
> @@ -78,9 +78,9 @@
>votes (whether General Resolutions or votes in the Technical
>Committee) in progress at the time the change is made.
> 
>The effect is to fix the [-fencepost-]{+off-by-one+} bug, and
>arrange that failing asupermajority voids the whole decision (or
>makes it advisory), rather than promoting another option.  The
>[-fencepost-]{+off-by-one+} bugfix will also have a (negligible)
>effect on any General Resolutions requiring supermajorities.  And
>after this change the TC chair can choose a non-default option even
>if it is tied with a default

Accepted.


Andi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV5GuNAAoJENrvwFpthGSOo60H/RGrlwEkq6jd2KkgzmrCOyWi
5T0Vh9Fr2eaKdmSzVNzO4w5a0vySCSyCGSTqwv/JVBXRN74prFBD6RKrGUKq2HKR
Jg2waPWLtSKGuLIuo65gaxkyKYSoQFuFy0aAXhpW06rEY2nSBtDxhaaxgUhIyfwp
SmHJD+oAqfEyUPKcSDLQMOC8iUtBBuZuOlCNNCOxKOa5wLp9bSItDNqb7yoK3tsM
5RcVRinFaAxhoqUV65psHcvZ/7wuguu5PYNpRXHWo74V01S/tZRtoVGwM6TzcqxI
qH2MAmErmRwkzCbaWTI9cL/iu4EFZyxevova6xQ/DVMCiT3vs30gTr+r4cXP9Z8=
=dUbC
-END PGP SIGNATURE-

In plain English please?! Re: General resolution: Changes to the Standard Resolution Procedure

[Dimitri John Ledkov]

Hello,

On 31 August 2015 at 08:06, Kurt Roeckx - Debian Project Secretary
 wrote:
> Hi,
>
> A new GR has been started to update the Standard Resolution
> Procedure.  Details about it can be found on:
> https://www.debian.org/vote/2015/vote_002
>

I'm failing to understand the current situation, nor proposed changes.
Can someone please give a plain English explanation and/or examples?

E.g. committee of size N is voting on an issue I which happens to be
overriding developer. The votes are F for, A against, S abstentions.
Previously this would fail, now this will pass.

Or something along these lines.

-- 
Regards,

Dimitri.

Re: In plain English please?! Re: General resolution: Changes to the Standard Resolution Procedure

[Don Armstrong]

On Mon, 31 Aug 2015, Dimitri John Ledkov wrote:
> On 31 August 2015 at 08:06, Kurt Roeckx - Debian Project Secretary
>  wrote:
> > Hi,
> >
> > A new GR has been started to update the Standard Resolution
> > Procedure.  Details about it can be found on:
> > https://www.debian.org/vote/2015/vote_002
> >
> 
> I'm failing to understand the current situation, nor proposed changes.
> Can someone please give a plain English explanation and/or examples?
> 
> E.g. committee of size N is voting on an issue I which happens to be
> overriding developer. The votes are F for, A against, S abstentions.
> Previously this would fail, now this will pass.

If the votes were 6 for (F), 2 against (A), 0 abstensions (S) for a
resolution which required 3:1 majority, currently, such a resolution
would not pass. This changes it so that it would.

This isn't usually an issue in general votes, but is a problem on the
CTTE.

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

I'm sorry about those late night emails.
I only said those things because I was too drunk
to be afraid.
  -- a softer world #579
 http://www.asofterworld.com/index.php?id=579

Re: In plain English please?! Re: General resolution: Changes to the Standard Resolution Procedure

[Russ Allbery]

Dimitri John Ledkov  writes:

> I'm failing to understand the current situation, nor proposed changes.
> Can someone please give a plain English explanation and/or examples?

> E.g. committee of size N is voting on an issue I which happens to be
> overriding developer. The votes are F for, A against, S abstentions.
> Previously this would fail, now this will pass.

In a supermajority-required TC vote involving eight TC members, currently
a supermajority of 6 can override a minority of 2, since this meets the
current 3:1 ratio.  After this change, the supermajority vote has to be
strictly greater than 3:1, so a vote of 6-2 would not pass the
supermajority requirement.

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

Re: In plain English please?! Re: General resolution: Changes to the Standard Resolution Procedure

[Russ Allbery]

Russ Allbery  writes:
> Dimitri John Ledkov  writes:

>> I'm failing to understand the current situation, nor proposed changes.
>> Can someone please give a plain English explanation and/or examples?

>> E.g. committee of size N is voting on an issue I which happens to be
>> overriding developer. The votes are F for, A against, S abstentions.
>> Previously this would fail, now this will pass.

> In a supermajority-required TC vote involving eight TC members, currently
> a supermajority of 6 can override a minority of 2, since this meets the
> current 3:1 ratio.  After this change, the supermajority vote has to be
> strictly greater than 3:1, so a vote of 6-2 would not pass the
> supermajority requirement.

Apologies: I wrote that exactly backwards.  This teaches me to write email
while people are trying to talk to me.  The above description is correct,
except that what I said was the new state is the current state, which this
GR is changing.

Currently, a supermajority of 6 cannot override a minority of 2.  After
this GR, that would again be possible.

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

Re: In plain English please?! Re: General resolution: Changes to the Standard Resolution Procedure

[Kurt Roeckx]

On Mon, Aug 31, 2015 at 04:49:08PM +0100, Dimitri John Ledkov wrote:
> Hello,
> 
> On 31 August 2015 at 08:06, Kurt Roeckx - Debian Project Secretary
>  wrote:
> > Hi,
> >
> > A new GR has been started to update the Standard Resolution
> > Procedure.  Details about it can be found on:
> > https://www.debian.org/vote/2015/vote_002
> >
> 
> I'm failing to understand the current situation, nor proposed changes.
> Can someone please give a plain English explanation and/or examples?
> 
> E.g. committee of size N is voting on an issue I which happens to be
> overriding developer. The votes are F for, A against, S abstentions.
> Previously this would fail, now this will pass.

One of the problems, and I consider that to be the most important
one, is about the stratigic vote that you can do.  For example,
condiser that there are 2 options (A and B) plus the default option
All options are acceptable for everybody, but 75% prefer A
and 25% prefer B.  You would except the following vote:
75%: 123
25%: 213

Option A would win as expected.

If there is a 3:1 majority requirement, you could instead vote:
75%: 123
25%: 312

As in, the 2nd group says that option A is not acceptable while in
fact it was.

This results in the option A being dropped because it does not
reach majority.  75% say A acceptable and 25% say it's not resulting
in a 3:1 majority saying it's acceptable.  The 75% just don't
reach the "strictly greater" than the 3:1 majority requirement.

In the end option B wins because of stratigic voting, while if
they were honest option A would have won.

The solution to this problem is moving the majority check later
in the process, so that option B would have been dropped first.
If they did this stratigic voting in that case both options would
have been dropped.


Kurt

Re: General resolution: Changes to the Standard Resolution Procedure

[Didier 'OdyX' Raboud]

Hi Axel,

(CC'ing aba, as GR proposer).

Le lundi, 31 août 2015, 10.26:18 Axel Beckert a écrit :
> Kurt Roeckx - Debian Project Secretary wrote:
> > https://www.debian.org/vote/2015/vote_002
> 
> Please either do not use the word combination "fencepost bug" at all
> or explain its meaning.

These words are in the original GR proposal [0], so this would need to 
be amended for clarity.

> As far as I could find out it refers to a political joke (!) in the
> USA comparing a "fencepost turtle" to e.g. George W. Bush or Sarah
> Palin. I don't think such a term is suitable for being used in a
> Debian GR.
> 
> (In case I'm wrong with my interpretation of that term, it proves my
> point even more: Please either don't use it or explain it because the
> term is obviously unclear.)

I understand this "fencepost bug" to refer to the fencepost error [1], 
quoting Wikipedia:

> A fencepost error (occasionally called a telegraph pole or lamp-post
> error) is a specific type of off-by-one error. The following problem
> illustrates the error:
>
> > If you build a straight fence 30 meters long with posts spaced 3
> > meters apart, how many posts do you need?
> 
> The intuitive answer 10 is wrong. The fence has 10 sections, but 11
> posts.

Is it clearer, and enough for you, or would you like to propose a GR 
amendment?

Cheers, OdyX

[0] https://lists.debian.org/20150826201241.gf9...@mails.so.argh.org
[1] https://en.wikipedia.org/wiki/Off-by-one_error#Fencepost_error

signature.asc
Description: This is a digitally signed message part.

Re: General resolution: Changes to the Standard Resolution Procedure

[Axel Beckert]

Hi,

Didier 'OdyX' Raboud wrote:
> Le lundi, 31 août 2015, 10.26:18 Axel Beckert a écrit :
> > Kurt Roeckx - Debian Project Secretary wrote:
> > > https://www.debian.org/vote/2015/vote_002
> > 
> > Please either do not use the word combination "fencepost bug" at all
> > or explain its meaning.
> 
> These words are in the original GR proposal [0], so this would need to 
> be amended for clarity.

*sigh*

> I understand this "fencepost bug" to refer to the fencepost error [1], 
> quoting Wikipedia:
> 
> > A fencepost error (occasionally called a telegraph pole or lamp-post
> > error) is a specific type of off-by-one error.
[...]
> Is it clearer,

Yes.

> and enough for you,

I would have preferred if "off-by-one" would have been used instead of
"fencepost" as in the subject of the original GR proposal. That term
is later missing in the announcement by Kurt as well as on
https://www.debian.org/vote/2015/vote_002

"off-by-one" is very common, self-descriptive and well-known even
among non-native speakers. "fencepost" is not. At least I haven't
heard of that term in the 20 years of my CS career, nor does it show
up with "translate" nor does dict.leo.org know about it. (The latter
just pointed me to the political jokes. And that seemed to fit:
Sounded like the TC is the turtle on the fencepost.)

Well, I'm at least glad, that nobody intended to refer to political
jokes in a Debian GR.

> or would you like to propose a GR amendment?

As far as I understand this would mean proposing an alternative choice
for the voter. In that case, the damage is already done and cannot be
undone. This IMHO only makes sense if I'd propose different semantics.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Re: General resolution: Changes to the Standard Resolution Procedure

[martin f krafft]

also sprach Axel Beckert  [2015-08-31 10:26 +0200]:
> Please either do not use the word combination "fencepost bug" at all
> or explain its meaning.
> 
> As far as I could find out it refers to a political joke (!) in the
> USA comparing a "fencepost turtle" to e.g. George W. Bush or Sarah
> Palin.

It's not: https://en.wikipedia.org/wiki/Off-by-one_error

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
windows v.i.s.t.a.: viruses, infections, spyware, trojans and adware


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: General resolution: Changes to the Standard Resolution Procedure

[Axel Beckert]

Hi,

Kurt Roeckx - Debian Project Secretary wrote:
> https://www.debian.org/vote/2015/vote_002

Please either do not use the word combination "fencepost bug" at all
or explain its meaning.

As far as I could find out it refers to a political joke (!) in the
USA comparing a "fencepost turtle" to e.g. George W. Bush or Sarah
Palin. I don't think such a term is suitable for being used in a
Debian GR.

(In case I'm wrong with my interpretation of that term, it proves my
point even more: Please either don't use it or explain it because the
term is obviously unclear.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: Digital signature

Re: General resolution: Changes to the Standard Resolution Procedure

[Didier 'OdyX' Raboud]

Andreas: GR amendment proposal below.

Le lundi, 31 août 2015, 11.04:59 Axel Beckert a écrit :
> I would have preferred if "off-by-one" would have been used instead of
> "fencepost" as in the subject of the original GR proposal. That term
> is later missing in the announcement by Kurt as well as on
> https://www.debian.org/vote/2015/vote_002
> 
> "off-by-one" is very common, self-descriptive and well-known even
> among non-native speakers. "fencepost" is not. (…)
> 
> > or would you like to propose a GR amendment?
> 
> As far as I understand this would mean proposing an alternative choice
> for the voter. In that case, the damage is already done and cannot be
> undone. This IMHO only makes sense if I'd propose different
> semantics.

The GR proposer can accept formal wording changes directly on his 
amendment proposal (§A.1.5).

I think the change would clarify the GR for more voters than only you, 
so I'm hereby asking Andreas whether he'd accept a wording change on his 
GR proposal as follows (%s/fencepost/off-by-one/g), under §A.1.5:

--- a/vote_002
+++ b/vote_002
@@ -7,7 +7,7 @@
   Committee could overrule a Developer with a supermajority of 3:1.

   Unfortunately, the definition of supermajorities in the SSD GR has a
   [-fencepost-]{+off-by-one+} error.  In the new text a supermajority
   requirement is met only if the ratio of votes in favour to votes
   against is strictly greater than the supermajority ratio.

@@ -78,9 +78,9 @@
   votes (whether General Resolutions or votes in the Technical
   Committee) in progress at the time the change is made.

   The effect is to fix the [-fencepost-]{+off-by-one+} bug, and
   arrange that failing asupermajority voids the whole decision (or
   makes it advisory), rather than promoting another option.  The
   [-fencepost-]{+off-by-one+} bugfix will also have a (negligible)
   effect on any General Resolutions requiring supermajorities.  And
   after this change the TC chair can choose a non-default option even
   if it is tied with a default

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: General resolution: Changes to the Standard Resolution Procedure

[Axel Beckert]

Hi Didier,

Didier 'OdyX' Raboud wrote:
> Le lundi, 31 août 2015, 11.04:59 Axel Beckert a écrit :
> > I would have preferred if "off-by-one" would have been used instead of
> > "fencepost" as in the subject of the original GR proposal. That term
> > is later missing in the announcement by Kurt as well as on
> > https://www.debian.org/vote/2015/vote_002
> > 
> > "off-by-one" is very common, self-descriptive and well-known even
> > among non-native speakers. "fencepost" is not. (…)
> > 
> > > or would you like to propose a GR amendment?
> > 
> > As far as I understand this would mean proposing an alternative choice
> > for the voter. In that case, the damage is already done and cannot be
> > undone. This IMHO only makes sense if I'd propose different
> > semantics.
> 
> The GR proposer can accept formal wording changes directly on his 
> amendment proposal (§A.1.5).

Ah, I wasn't aware of this.

> I think the change would clarify the GR for more voters than only you, 
> so I'm hereby asking Andreas whether he'd accept a wording change on his 
> GR proposal as follows (%s/fencepost/off-by-one/g), under §A.1.5:

Thanks! Much appreciated!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE