Hi all,

Let me start by apologizing for taking this long to send this email. The attentive reader will have noticed my name in Russ' original draft as
one of the people who reviewed it. When Russ sent his initial proposal,
I started drafting a large response that I lost due to a silly mistake
on my end. Life then intervened, and I didn't have time to follow up
until now.

That said,

I think introducing a fixed time limit on a GR is a bad idea, for
various reasons.

First of all, no matter how careful we choose a time limit based on
historical precedence, I think it is naive to assume we will be able to
come up with a time limit that will always work for all future GR
proposals. Some issues are contentious, and they take time to work
through them. In my reading, the longest we have ever taken to decide on
a vote was for GR 2006-003, where the initial proposal was sent in June
but the eventual vote only opened in September[1].

An argument that has been brought forward to avoid that problem is that
it is theoretically possible to discuss matters on this list before
starting the formal procedure. While that is true, I would like to point
out that the whole reason for the introduction of this time limit is so
that people can't game the system by using procedural measures to delay
the vote, possibly indefinitely. If we don't want to allow people to
delay the vote, we should *also* not allow people to game the system by
forcing a vote prematurely, through proposing a formal GR when someone
else offers incomplete ideas that they would have preferred to see
discussed first. Again, I would point to GR 2006-003 where something
along those lines happened[1].

I fear that in order to avoid that pitfall, people may wish to discuss
things in private amongst themselves rather than posting something to
the -vote list when they want to start looking at a problem, which will
give them an unfair time advantage.

Additionally, it is not always possible to foresee all of the complexity
in a problem space; we may be quite a bit into the formal discussion of
the ballot when we decide that there are some significant issues that
require exploring and which would benefit from more time. If everyone
involved agrees that this is a good thing, then I think we should allow
for that possibility; the proposed procedure does not do so, and I fear
that this may result in rushed proposals that are suboptimal and do not
resolve the issue at hand.

An argument that has been brought forward to remedy this is that it is theoretically possible to advance a vote for the default option in such
a case. While this is true, that is problematic: first of all, it will
delay the resolution of the situation by a significantly larger amount
of time (you will need to go through a complete vote only to have to do
the whole process over again). I think it is relevant in this context
that we only managed to do this one time in the history of the project,
in a vote where I can't help but feel like the proponents of the vote
tried to game the system (2006-005[2]).

We might have been able to use this for 2004-004, but alas.

Additionally, I believe that proposing we vote the default option more
often is antithesis to what we *should* be doing. I think a GR vote
should generally be the final answer to an issue we are dealing with,
and that in order to do that, we should ensure that the ballot is
complete, with all relevant options represented. I don't think we get
that if we introduce a rigid timeline that cannot be diverted from in exceptional situations.

I hear and agree with the argument against such a procedure; having a
way to delay the vote which everyone can trigger opens the system up to
abuse, which could allow the vote to be delayed indefinitely if
formulated badly. I believe the answer to that is not to remove the
option to delay the vote entirely, but to restrict the conditions under
which such a delay can be invoked; only provide it to the DPL, or
provide only a limited number of delays, or allow a majority of people
who proposed options that are already on the ballot to object, or
something along those lines. The goal should be to end up with a
procedure where *can* extend the discussion period if discussions are
actually still happening and we believe it is valid, without allowing
people who want to avoid any vote from happening entirely to delay
things indefinitely.

Additionally, this proposal does not remedy what I think is another
issue we have with our procedure, which I have been wanting to resolve
one way or the other for quite a while but have no idea how to do so;
the "I want to create a ballot with all possible options" antipattern.
We had a few cases of this over the years (at least two that I can
remember), usually by well-intentioned people who want to get things to
a vote quickly, but I honestly believe it creates more problems than it attempts to solve.

Writing an option that does not represent your own personal opinion is extremely difficult at best, and is probably not even possible at all.
This means you'll get proposals from people who actually hold an opinion
very close to what you wrote down that you'll then need to evaluate to
decide whether this improves the ballot option, or whether it changes
the option into something different entirely and thus should be a
separate ballot option instead. To deal with such a proposal from the
point of view of someone who feels one of the options is
almost-but-not-quite something you can vote for can be very frustrating,
as I experienced first-hand in https://lists.debian.org/debian-vote/2019/11/msg00032.html .

I also believe that a ballot with options that were written by people
who do not support that option will usually result in a cluttered
ballot, with various options that are almost but not quite the same
thing, and options that are irrelevant noise and which will never win. I
think this behavior should be discouraged if not outright forbidden
(although, again, I'm not sure how to forbid them), and would note that
adding a strict time limit seems more likely to create private
discussions (as I've explained above) and therefore to me seems more
likely to result in this antipattern.

I'm not submitting a formal draft to go against yours at this point
(although I do have the beginnings of one), because I would like to see
whether I'm alone in this opinion or not, where only in the latter case
it would make sense to continue down this path.

Thanks for your thoughts,

[1] In the case of 2006-003, I started a discussion on -vote in order to
start the debate before formally proposing a GR, intending to
explore the problem before starting to build the ballot. The first
follow-up to that mail however was a formal GR proposal by Manoj,
which then started the procedure. It was not contentious vote
though, and I think technically the vote may have expired at least
once, although I'm not 100% sure about that -- it involved a few
amendments resetting the timer and the DPL extending the minimum
discussion period after one of them, so the details are a bit
muddy.
[2] In 2006-005, Denis Barbier proposed a vote to recall the project
leader. The DPL then delegated the authority to vary the discussion
and voting periods to him and Lo�c Minier. Denis chose to not accept
any amendments and reduced the discussion time to the minimum, and
called for a vote while, in my opinion, the discussion was still in
full force.

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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEm2n98/DaCUgGYSn3LfxRmVQYEpYFAmFy9+8ACgkQLfxRmVQY EpYzTA/+I3DlUFD5JNHstxWCZLGk7vA9eKihyeXeKDyRwSlCO2Wtgch9494F9E4F jawoFUtac6o6Mco6GL5xy2s42w2O/YZngnuM3Px5yUeDVQxzfuVoCVFWKj46Tb9t 5/ICB33bTrz/OKJ79XSIDjeKYNdlFTVVvrjepe+rorgEH6kcTmrnR9pQSwXD0HKX WG2DHXo02aRnRp9mLCQXTil4I1wSLmvjKCONDyGcRltQh7Yz/v/mYos0UAErtqqe ovQVPLZ0fjbCp4Q20s/0PmCYUVb/pBgExjbnFuKqQK+2V6ALvNsadterHhnuDMCL Siv51r8+hhLA/yfgCNy1VJz4OMmi8bxK2PBZHOufLGoeku9NChEqvo84ngON/Gt3 l9gsqWk3OkvbdfqLLsVVIJHbgLaMp7sdg8F/tPWvb1h5BeqySL6zfJU4WAbr5Kvz RL6N8tHvSF0oZTpdbSLcBRYw7khmANgpy6QmomnMM2jl46H9c9WJ27Xqjaylt7pQ A5v+rXmp5s3wmQDlOuApYIY/3pmiWzte31hVbWjZqZ/7BZT87haTrVeBdK58CHqK nipFm9v3i3AQ/oiqnB/8qdfChOmng/zAWVpsNqUb9lgjWkyaF84tL/bOqyVi5n0+ nmgVsDedFtjKP+qmbg1tVnBHo+0iAYLM2upyEuW3Ng+nuBXz6YU=
=seVe
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thank you for raising this, Wouter!

I'm not going to reply directly to the substance of this argument right
now because Wouter already knows my opinion and I think having the rest of
the project weigh in would be much more useful. Part of the goal here is
to come up with a system that's more predictable and fair for everyone, so
if having prolonged discussion periods is important to others, I'd like us
to have that discussion so that we can explore the nuances.

I did want to make one technical point, though:

Wouter Verhelst <wouter@debian.org> writes:

I think introducing a fixed time limit on a GR is a bad idea, for
various reasons.

It's fair to say that my proposal introduces a fixed time limit in the
sense that the current constitution *in theory* allows the discussion
period to be unbounded.

However, I think it's important to note that *in practice* the current constitution also has a time limit on a GR, which can only be increased
(beyond the week allowed to the DPL) by either the original proposer of
the GR (not the proposer of any other ballot option) by regularly
accepting new amendments, or by the cooperative choice of every Debian Developer to not call for a vote. In practice, without the active
cooperation of the proposer of the GR, the current constitution imposes a
fixed time limit of two weeks on the discussion period (or three weeks
with a DPL extension). It just doesn't automatically enforce this and
instead leaves it to any Debian Developer to enforce it, which means in practice it sometimes runs a bit longer but generally not that much
longer.

Under the current constitution, once two weeks have passed, unless the
original GR proposer accepts an amendment to reset the clock, any Debian Developer can force a vote by seconding the original proposal and then
calling for a vote.

This means that the discussion period could be unbounded in cordial cases
where no one is in any hurry and no one wants to force the issue, but as
soon as the proposal becomes controversial in some way, it's highly likely
that someone will impose the time limit and force a vote. (Whether you consider that a feature or a bug of course depends on your opinion about extended discussion periods.)

To fully achieve what Wouter is calling for would therefore *also* require
a constitutional change. It's not a preservation of the existing status
quo. I know Wouter knows that, but I wanted to make sure it was explicit
for everyone else.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Wouter Verhelst <wouter@debian.org> wrote on 22/10/2021 at 19:42:13+0200:

[[PGP Signed Part:No public key for 2DFC519954181296 created at 2021-10-22T19:42:07+0200 using RSA]]
Hi all,

Let me start by apologizing for taking this long to send this email. The attentive reader will have noticed my name in Russ' original draft as
one of the people who reviewed it. When Russ sent his initial proposal,
I started drafting a large response that I lost due to a silly mistake
on my end. Life then intervened, and I didn't have time to follow up
until now.

That said,

I think introducing a fixed time limit on a GR is a bad idea, for
various reasons.

First of all, no matter how careful we choose a time limit based on historical precedence, I think it is naive to assume we will be able to
come up with a time limit that will always work for all future GR
proposals. Some issues are contentious, and they take time to work
through them. In my reading, the longest we have ever taken to decide on
a vote was for GR 2006-003, where the initial proposal was sent in June
but the eventual vote only opened in September[1].

An argument that has been brought forward to avoid that problem is that
it is theoretically possible to discuss matters on this list before
starting the formal procedure. While that is true, I would like to point
out that the whole reason for the introduction of this time limit is so
that people can't game the system by using procedural measures to delay
the vote, possibly indefinitely. If we don't want to allow people to
delay the vote, we should *also* not allow people to game the system by forcing a vote prematurely, through proposing a formal GR when someone
else offers incomplete ideas that they would have preferred to see
discussed first. Again, I would point to GR 2006-003 where something
along those lines happened[1].

I fear that in order to avoid that pitfall, people may wish to discuss
things in private amongst themselves rather than posting something to
the -vote list when they want to start looking at a problem, which will
give them an unfair time advantage.

Additionally, it is not always possible to foresee all of the complexity
in a problem space; we may be quite a bit into the formal discussion of
the ballot when we decide that there are some significant issues that
require exploring and which would benefit from more time. If everyone involved agrees that this is a good thing, then I think we should allow
for that possibility; the proposed procedure does not do so, and I fear
that this may result in rushed proposals that are suboptimal and do not resolve the issue at hand.

An argument that has been brought forward to remedy this is that it is theoretically possible to advance a vote for the default option in such
a case. While this is true, that is problematic: first of all, it will
delay the resolution of the situation by a significantly larger amount
of time (you will need to go through a complete vote only to have to do
the whole process over again). I think it is relevant in this context
that we only managed to do this one time in the history of the project,
in a vote where I can't help but feel like the proponents of the vote
tried to game the system (2006-005[2]).

We might have been able to use this for 2004-004, but alas.

Additionally, I believe that proposing we vote the default option more
often is antithesis to what we *should* be doing. I think a GR vote
should generally be the final answer to an issue we are dealing with,
and that in order to do that, we should ensure that the ballot is
complete, with all relevant options represented. I don't think we get
that if we introduce a rigid timeline that cannot be diverted from in exceptional situations.

I hear and agree with the argument against such a procedure; having a
way to delay the vote which everyone can trigger opens the system up to abuse, which could allow the vote to be delayed indefinitely if
formulated badly. I believe the answer to that is not to remove the
option to delay the vote entirely, but to restrict the conditions under
which such a delay can be invoked; only provide it to the DPL, or
provide only a limited number of delays, or allow a majority of people
who proposed options that are already on the ballot to object, or
something along those lines. The goal should be to end up with a
procedure where *can* extend the discussion period if discussions are actually still happening and we believe it is valid, without allowing
people who want to avoid any vote from happening entirely to delay
things indefinitely.

Additionally, this proposal does not remedy what I think is another
issue we have with our procedure, which I have been wanting to resolve
one way or the other for quite a while but have no idea how to do so;
the "I want to create a ballot with all possible options" antipattern.
We had a few cases of this over the years (at least two that I can
remember), usually by well-intentioned people who want to get things to
a vote quickly, but I honestly believe it creates more problems than it attempts to solve.

Writing an option that does not represent your own personal opinion is extremely difficult at best, and is probably not even possible at all.
This means you'll get proposals from people who actually hold an opinion
very close to what you wrote down that you'll then need to evaluate to
decide whether this improves the ballot option, or whether it changes
the option into something different entirely and thus should be a
separate ballot option instead. To deal with such a proposal from the
point of view of someone who feels one of the options is
almost-but-not-quite something you can vote for can be very frustrating,
as I experienced first-hand in https://lists.debian.org/debian-vote/2019/11/msg00032.html .

I also believe that a ballot with options that were written by people
who do not support that option will usually result in a cluttered
ballot, with various options that are almost but not quite the same
thing, and options that are irrelevant noise and which will never win. I think this behavior should be discouraged if not outright forbidden (although, again, I'm not sure how to forbid them), and would note that adding a strict time limit seems more likely to create private
discussions (as I've explained above) and therefore to me seems more
likely to result in this antipattern.

I'm not submitting a formal draft to go against yours at this point
(although I do have the beginnings of one), because I would like to see whether I'm alone in this opinion or not, where only in the latter case
it would make sense to continue down this path.

Thanks for your thoughts,

[1] In the case of 2006-003, I started a discussion on -vote in order to
start the debate before formally proposing a GR, intending to
explore the problem before starting to build the ballot. The first
follow-up to that mail however was a formal GR proposal by Manoj,
which then started the procedure. It was not contentious vote
though, and I think technically the vote may have expired at least
once, although I'm not 100% sure about that -- it involved a few
amendments resetting the timer and the DPL extending the minimum
discussion period after one of them, so the details are a bit
muddy.
[2] In 2006-005, Denis Barbier proposed a vote to recall the project
leader. The DPL then delegated the authority to vary the discussion
and voting periods to him and Loïc Minier. Denis chose to not accept
any amendments and reduced the discussion time to the minimum, and
called for a vote while, in my opinion, the discussion was still in
full force.

While there is a lot of sensible points here, I am quite convinced that
having no strong time limit can and already have done more harm than
what this time limit could do.

I think that if people are not able to explore a discussion in several
weeks, then there's no hope for it to be in a better shape with one more
month.

Of course, if the future shows otherwise, we could still rollback this particular aspect.

Cheers!

--
PEB

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJDBAEBCgAtFiEESYqTBWsFJgT6y8ijKb+g0HkpCsoFAmFzDigPHHBlYkBkZWJp YW4ub3JnAAoJECm/oNB5KQrK/xkP+wUMlM18Cl3884SccZ58G8W1v+rNjLRv5b7L jbRn2XE1/j+E61HvqhJvO5ESf92H9ogzNBEe+rsC/2ckG2x4fcp3GuXd2+JFmYQq 9Xj1jNVRlVisioXDvd+Gy+Bb2yVbPPKMlYD94GudC5sxX414AkC5WL8HO8IM3l9u l5nl0Rt3nuA8XMqwcZEyi6mX9LM5/kGJKw5Of/VlGuvxHglqjOF5pnZJ2mh4r6YF IO8bp1+qq1t5Uk/QkNLGzcNlExetaGhTdDotdZcyyYnYm+iJ/4MsWB4t0Uh57Ha5 kKkahtV/ZHlauxMcbLuXYXHJCE3ZQEFMXRDBN+xSr04cSuWE3eZqsokfW0AFGK0s Ornb2VUtJjZPvL5Yrj9bvEfkcM1XMwNDiX2pOG1+Mb84FPSMSUj7SOlTv2ffGk3t 1vVhcRRFqPN2EaFtW9rTUYacZWiRl+GHiFiAHjS/4Z6watBJjCz35NLdfRXPsEYp Rf3a21fi65CjCsOcp7vgV0JwuV7i95mZDVARaCfCs2Yd5MGARuFeJMfK0OmH98E+ hrcTRuiM+cPUtiw/gs5ZUhADrnX2SemBO1e2hwrbXEM2u3AwMUpEK6JieVVAk4W0 RIrDrCb7b2U1Sx5m2hlkN/DTUqdnu2WFRphKi/ts8bLvd6sYNbsyXyyNS0yXW2hc
k6Ewn45D
=rbVJ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gRmfdOzVahOo5zgIA7f4qvf2TYMOF3BGY
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

In general, I understand the reasoning for having an option for longer discussions. However, I see risks too.

On 10/22/21 12:42 PM, Wouter Verhelst wrote:

a vote to recall the project leader.

This is an interesting corner case. I don't think it needs a special
case under the current situation or Russ's proposal, as the time is not unbounded. But we should be careful not to make the time unbounded
except by DPL action ("only provide it to the DPL") as that would
effectively insulate the DPL from recall.

--
Richard


--gRmfdOzVahOo5zgIA7f4qvf2TYMOF3BGY--

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE1Ot9lOeOTujs4H+U+HlhmcBFhs4FAmFzIVEACgkQ+HlhmcBF hs6IBQ//Zy04OhdAlMosPgRv+vX1cqIzeaJDSgRAZJfd6frOL2MWvyi8raKGG1Fl jZtWd3dz3w+5E97fJX9O0OIWxVg93jVfMisd/AkvxesT7//YJavnRhiUkTg2Rvzm tIj6jKjwmByz8h2QJoPEJs1Wgq3ztYtmPmkGRxUabhqipksTeL+zBz3KBSy2wyXh GOkrFj0v5ree5z2yspfvL1BABBfyvrrL9ISbcCMhPPmg1ycOkFijpN+gfIK2D5m1 VL8pQTN96ZJ3ptq980/4GW5i01K5ewKTX8LtTjlm0ur5lSV2eoMLP5A0pmi5oRRS k2jVZQ485iMfYYtLOCfYJ4w2uI5BwVlBbU+5wmpwVeRB5bk8Rw18U+SQnTOryYId caK/yF/bKhM6Mnm/jksGqr323EA+Al/02FdHFQFZDMmP8CHgiu79rDaBu98q/kD/ loOAxWEbuV2tHZ+mUW0m/8eUeWq3eyPXK2yLEQwaKYDgGOm/XW1CZdnIZAAMeYOi GA5me/Udkf4/orrXWlNXMx6tDFse3+xQOJAIw+KYgJG9KbiLq8Zl1mh+yfY4Guha Ns23nzfdzUkGpzE5cw3xg9U8QgHJMKeMuoRyje1MNh/xvpDKp/gWX4YaAeqsV7eK VMp6IIjxdErNguqskESqm4fmBgvR7aAb3vwwcePexcRi+ga1K1Q=
=5XGn
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Fri, Oct 22, 2021 at 11:23 AM Russ Allbery <rra@debian.org> wrote:

To fully achieve what Wouter is calling for would therefore *also* require
a constitutional change.

As a proponent of a living process, I would welcome such an
alternative on the ballot.

Russ's motivation strikes me as extremely noble: With rules, people
feel treated fairly. At the same time, better rules do not make better decisions. For Debian—a free-spirited volunteer project—I find
Wouter's vision of a healthy and flexible democratic process more
compelling. Why not put the people first?

Being new, I wrote with some hesitation. Thank you for reading!

Kind regards
Felix Lechner

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Russ,

On Fri, Oct 22, 2021 at 11:22:36AM -0700, Russ Allbery wrote:

To fully achieve what Wouter is calling for would therefore *also* require
a constitutional change. It's not a preservation of the existing status
quo. I know Wouter knows that, but I wanted to make sure it was explicit
for everyone else.

I concur -- and to expand on this a bit, I'd like to clarify a bit:

I think we agree that the rules for timing in the current constitution
are a bit messed up. The initial proposer of a GR has powers to affect
the timing that don't strictly belong with that person, and these powers
can be abused. I think we both agree that this needs adjusting.

The difference is in how we would adjust things: your draft proposes to
take that power away entirely, whereas I think a better way forward is
to adjust who can use those powers.

I also don't want to create a situation where the process is fully
unbounded. Currently, effectively everyone can call for a vote at pretty
much any time after a minimal time has passed. I think this is a
feature, not a bug, of our current system, and I want to retain that
feature. I understand that you disagree.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Wouter" == Wouter Verhelst <wouter@debian.org> writes:

Wouter> I hear and agree with the argument against such a procedure;
Wouter> having a way to delay the vote which everyone can trigger
Wouter> opens the system up to abuse, which could allow the vote to
Wouter> be delayed indefinitely if formulated badly. I believe the
Wouter> answer to that is not to remove the option to delay the vote
Wouter> entirely, but to restrict the conditions under which such a
Wouter> delay can be invoked; only provide it to the DPL, or provide
Wouter> only a limited number of delays, or allow a majority of
Wouter> people who proposed options that are already on the ballot
Wouter> to object, or something along those lines. The goal should
Wouter> be to end up with a procedure where *can* extend the
Wouter> discussion period if discussions are actually still
Wouter> happening and we believe it is valid, without allowing
Wouter> people who want to avoid any vote from happening entirely to
Wouter> delay things indefinitely.

Wouter> Additionally, this proposal does not remedy what I think is
Wouter> another issue we have with our procedure, which I have been
Wouter> wanting to resolve one way or the other for quite a while
Wouter> but have no idea how to do so; the "I want to create a
Wouter> ballot with all possible options" antipattern. We had a few
Wouter> cases of this over the years (at least two that I can
Wouter> remember), usually by well-intentioned people who want to
Wouter> get things to a vote quickly, but I honestly believe it
Wouter> creates more problems than it attempts to solve.

Wouter> Writing an option that does not represent your own personal
Wouter> opinion is extremely difficult at best, and is probably not
Wouter> even possible at all. This means you'll get proposals from
Wouter> people who actually hold an opinion very close to what you
Wouter> wrote down that you'll then need to evaluate to decide
Wouter> whether this improves the ballot option, or whether it
Wouter> changes the option into something different entirely and
Wouter> thus should be a separate ballot option instead. To deal
Wouter> with such a proposal from the point of view of someone who
Wouter> feels one of the options is almost-but-not-quite something
Wouter> you can vote for can be very frustrating, as I experienced
Wouter> first-hand in
Wouter> https://lists.debian.org/debian-vote/2019/11/msg00032.html .

Wouter> I also believe that a ballot with options that were written
Wouter> by people who do not support that option will usually result
Wouter> in a cluttered ballot, with various options that are almost
Wouter> but not quite the same thing, and options that are
Wouter> irrelevant noise and which will never win. I think this
Wouter> behavior should be discouraged if not outright forbidden
Wouter> (although, again, I'm not sure how to forbid them), and
Wouter> would note that adding a strict time limit seems more likely
Wouter> to create private discussions (as I've explained above) and
Wouter> therefore to me seems more likely to result in this
Wouter> antipattern.

Wouter> I'm not submitting a formal draft to go against yours at
Wouter> this point (although I do have the beginnings of one),
Wouter> because I would like to see whether I'm alone in this
Wouter> opinion or not, where only in the latter case it would make
Wouter> sense to continue down this path.

Wouter> Thanks for your thoughts,

Wouter> [1] In the case of 2006-003, I started a discussion on -vote
Wouter> in order to start the debate before formally proposing a GR,
Wouter> intending to explore the problem before starting to build
Wouter> the ballot. The first follow-up to that mail however was a
Wouter> formal GR proposal by Manoj, which then started the
Wouter> procedure. It was not contentious vote though, and I think
Wouter> technically the vote may have expired at least once,
Wouter> although I'm not 100% sure about that -- it involved a few
Wouter> amendments resetting the timer and the DPL extending the
Wouter> minimum discussion period after one of them, so the details
Wouter> are a bit muddy. [2] In 2006-005, Denis Barbier proposed a
Wouter> vote to recall the project leader. The DPL then delegated
Wouter> the authority to vary the discussion and voting periods to
Wouter> him and Loïc Minier. Denis chose to not accept any
Wouter> amendments and reduced the discussion time to the minimum,
Wouter> and called for a vote while, in my opinion, the discussion
Wouter> was still in full force.

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


I'm reluctant to engage here, because I disagree strongly with Wouter,
and I don't think we're going to find consensus, and so at some level, I
think if Wouter finds enough support he should craft a ballot option and
I should vote it below other options.

However there is one area of agreement, and I'll focus there.
I agree that if a sufficient part of the project wants to continue the discussion, we should be able to do that.
I just don't see how to accomplish that in a way that is better than
what Russ proposes without being open to abuse.

There is an easy way to extend discussion in Russ's proposal.
If all ballot option proposers agree to withdraw their option, the vote
ends and discussion can continue.
Note that because in Russ's system proposers are different than
sponsors, you only need to convince a small number of people that
discussion needs to continue.

If you cannot convince one of the proposers, you can try to convince
their sponsors to withdraw.
If a GR process ends, the DPL's power can be used to shorten the minimum discussion period, and if you have everyone lined up to re-propose
options and sponsor them again once things are refined, the delay is
only a week or two.
(And if you need to delay discussion, you ought to be willing to accept
that delay).

This can work quite well in cases where the community strongly agrees discussion needs to be delayed.
But the bar for delaying discussion is high.

I don't know how to lower that bar without increasing the level of
abuse beyond what I'm comfortable with.

Giving the power to the DPL puts the DPL in a horrible position. No
matter what they do people are going to be screaming that the DPL has
abused the system. I think giving the DPL more power than in the
current system to affect vote timing will end up with situations where
people claim that the process is unfair, even when the DPL tries to be
careful.


Giving the power to the majority of ballot option proponents is open to
abuse; by stuffing the ballot some minority can delay the vote.
The counter of having people who hold other positions also stuff the
ballot so they have a majority seems highly undesirable.
In particular, it has the effect of ballot option proliferation which
Wouter wants to avoid.
Also, it gives power to the people who can be most vocal--getting the
most number of ballot options and most sponsors.
I think that will add flames to discussions rather than rationality.
I think it will encourage the voting discussions to be even more heated
than they are today, and so I don't think that is a good option.

One thing I've considered is to provide a quick way of running web polls
for procedural votes, like a vote to extend discussion.
I'm imagining a 48 or 72 hour poll to extend discussion; if a majority
of people who vote in the poll (open only to developers of course) vote
to extend discussion, then discussion would be extended.
That would be a significant change over how we do things.
I personally don't think it is worth the complexity, but if we adopted
such a system I think it would not be open to unreasonable levels of
abuse.

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCYXRZVQAKCRAsbEw8qDeG dAeeAP0S7rgXynJy7wHh/fLbFqcsbyAsU1XFrcVIcV2/OaevLwD+N9wiTGR+JSPs dRzUNhanFr4wmwYTK5czOBOn9NzARwY=ZJBX
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rwbIxID1iRrn3eXP8vaOOnaHKJzix0fzA
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 10/23/21 1:49 PM, Sam Hartman wrote:

I agree that if a sufficient part of the project wants to continue the discussion, we should be able to do that.
I just don't see how to accomplish that in a way that is better than
what Russ proposes without being open to abuse.

I think a great next step would be to see a proposal from Wouter. Maybe
there is some way. But we need something concrete to really discuss.

--
Richard


--rwbIxID1iRrn3eXP8vaOOnaHKJzix0fzA--

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE1Ot9lOeOTujs4H+U+HlhmcBFhs4FAmF0pxcACgkQ+HlhmcBF hs5+hw//S127vyqh7EDNaF46QgznHYf61eJaTNJ5BgHrAmOLxNNvZ0oXrW9ng+Jp VXJaP5DrbHp8Mw2ZtieobaFraKmPQ7FyiPnhIgmCOs4ALqwDtQ0SzpoI+9XCCZ29 hOR8/r6ZOJOftAfBseaXYkIgC0KR8GDIz1zfhTP5UBiY/H90h6Kz3WKmEDjP6gQi HujrgmwUyMQYV75Z5dcF6gSEedXHPX0SUTB6Rats0y7+AkT22BMv4xuypyYd8v/1 mX7yGF8uFiYNttSMPSY8Uuw2myhH9VVx6MM4upuTOA3i1a2ajNu8t5VnmUTPthfO hvcjZC0w+S3CIoW0qLe79vlYpMFBVy08c0ufnhDd6Vufml37UdzYh1F+JywhWvSJ Ja51MoYqc4lUyPHHlGsh3EWl9oxzAtkfzJ9yt2kXiozWJHSkmEaqarOy0P6Sxckw 5mDdjTLQqqQ7XxrqDOcMhLOAdjPLwTHRRGSfqvXa2VFlzAlnCA/PQLkS8R/zcQlT NwTsbScBDwMKl6ps0lUEjT+xfmxK9A1HkTGifBWkCYzGItFHI90SPTbXnsrJirxJ tik0fs+hvmsGbrftpWmzSe5z4RRkgM8Y0MYJC8LdZHfiB0nGTJbisQWRaR4OkJ4q 8CHhkO94v3OIIYAHWE29a6WpSnyCkCBa6PrpHFHl3WjyynDDqlE=
=0TJl
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Sam,

On Sat, Oct 23, 2021 at 12:49:57PM -0600, Sam Hartman wrote:

However there is one area of agreement, and I'll focus there.
I agree that if a sufficient part of the project wants to continue the discussion, we should be able to do that.
I just don't see how to accomplish that in a way that is better than
what Russ proposes without being open to abuse.

Thanks for this message. It caused me to reconsider what I think is most important, and how to accomplish it.

To me, what matters most is that the ballot is built in a way that makes
it most likely that all the relevant options are represented on the
ballot. Not necessary all the *possible* options -- there will always be
fringe opinions that are not supported by a significant amount of
people, but for those it doesn't really matter whether they're on the
ballot; if you can't even convince a handful of people that an option
should be voted on (let alone whether you *agree* with it), then it's
highly unlikely that that option will carry the vote.

However, the problem I see with strict timings that cannot be extended
in any possible scenario is that we may end up with a situation where
one option cannot be fleshed out entirely due to lack of time. I think
it's unrealistic to assume that in such a case everyone can be convinced
to postpone the vote by two weeks, *at least*, rather than extend the discussion time by a few days in order to allow the option that hasn't
finished gathering enough seconds to finish up and become acceptable to
enough people.

So what I think is important is to allow for a way to get a short amount
of extra time, *once*, in order to finish up a proposed ballot option.

This could be accomplished as follows:

- If you think you need more time to flesh out a ballot option, you can
formally request, on the -vote mailinglist, for more time.
- A request for more time can be seconded, with the same requirements in
terms of number of seconds to get an option on the ballot.
- If the request for more time achieves the required number of seconds,
then the discussion time will last until a certain amount of time (as
specified in the constitution) from when the request was made (i.e.,
the count would *not* start from when the discussion time would
currently expire).
- The process can be repeated as long as the discussion time has not
expired; but, crucially, anyone who seconded a previous extension
request cannot second another one (although you can *request* another
extension if you want).

In practice this would mean that if you have a significant level of
support for extending the discussion time, you can probably get the
discussion time extended twice, and *maybe* three times if you're lucky,
but I think it highly unlikely you'll be able to extend beyond that.

The thought process behind requiring the same level of support for a
time extension as compared to adding an option to the ballot is that
this way, someone could say "I like this proposal, but there are some
details that I would like to see changed before I am prepared to
formally support it". If there's only a limited amount of people who
feel that way, then wordsmithing is unlikely to result in a text that
will satisfy enough people to result in an extra ballot option. However,
if there are, then such an option does have a fighting chance of making
it on the ballot, and I think we should give the people advocating for
that option sufficient time to get there.

In order to make this process work, the time of a single extension
should be long enough so that a person who requests the extension has sufficient time to go to bed, wake up, go to work, come home, eat, draft
their proposed ballot option, post it to this list, and then have
sufficient time to allow for people to second it. That means that 24
hours is certainly going to be too short, but a full week is probably
going to be too much. I would suggest 72 hours at this point, but I'm
not married to that number.

With this process, we could also default the minimum discussion time to
be much shorter (say, one week or so); then if there is much to discuss,
after 6 days or so someone could suggest "we're clearly not there yet,
let's extend the discussion" and we can extend with this process.

If this process (or something similar) were to be incorporated in the
current draft, my objections to it would vanish.

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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEm2n98/DaCUgGYSn3LfxRmVQYEpYFAmF1j8AACgkQLfxRmVQY EpZm9g//XXqEh2hp8y5Wk05/C8LwisO5CtxLyMPpM9lDMfeHrsxwUxkfmEp8xqGG aj0AWih0Xzynne8QTcg7esLgNWTsnfS3jK2mcjGRifuLqkifIH1EPJjxmW9WoPke RPRY6/Ec3FVf3TovXZv0tVmwECx7LS3xizLniy9JXrHkc9PDeOJ0FfVnhdu7WkW0 MpwgcvcBbAHiwdiy/bOTyMS4c3T1ZI+JrrgW5VsELM4FV/X7wo/kp4yEcuAvCWvk taWDPL5dqsR6Fq9fhuyNiNTPpO01bPHyVK9uUNX6ukgkvySdFGb8agGfu+ROFaD6 LjnZkkigyTy8GPfgtGg2ymdsVvPeQ98JqFw/qa+ix6KpBCFt3p5kRxsStxTFNhnX +qkK/5yfknOPN+INvAs9Hg6ZAA8DMyhqnwnQz1TPXCRiN1MK7TjETKtqDu/Ldosd RbnqOAvzyMcMBjcl+AVJMjNADAiCs1DGxREVoiGQ8QzATJVbKo9YuHOGB+hzTYZS RcUadrBNj1GNEtmIiLxgIeCok1sG2lKROJY7FFXtunfcxHJ3pCXB/b5//L8zztwJ 3Mrm+k/RlayIV9aa/70w3F4dQfhU2Yr8mtRkurLTa0a0350hr8nqSIFR19PWw+J7 8eNUvsgDNaarv+CWvv5+yrspM3YqbJPWV5QyUreFnGtVo4KwC8w=
=/LoW
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On second thought...

On Sun, Oct 24, 2021 at 06:54:51PM +0200, Wouter Verhelst wrote:

With this process, we could also default the minimum discussion time to
be much shorter (say, one week or so); then if there is much to discuss, after 6 days or so someone could suggest "we're clearly not there yet,
let's extend the discussion" and we can extend with this process.

This bit (which was meant to have discussion times as short as possible
by default, allowing to extend things if necessary) is probably a
mistake. The process I wrote down, by design, makes it more difficult as
time goes on to extend the discussion time even further; if I say that I believe 3 weeks may not be enough in contentious debates (and I still
believe that), then reducing the time to 1 week by default and expecting
it to be extended until 3 weeks have passed is probably not a good idea.

So instead, scratch that bit. What we could do though is allow the DPL
to reduce the discussion time from 3 weeks down to one week (but not
up), and allow this process to be used on top of that if and when
necessary.

I also think now that perhaps allowing someone to propose multiple
extensions (and only limiting seconds) could be a bad idea, so I think
it might be better to limit proposers too.

In somewhat more formal language, apply the following changes to Russ'
draft (sections that remain unchanged from his draft are skipped below):

---
A.1. Discussion and amendment.

1. The discussion period starts when a draft resolution is proposed and sponsored. The default discussion period is 3 weeks.

[...]

4. (removed, does not apply; for clarity, the following are not
renumbered although they would have to be in a final proposal)

[...]

6. The project leader may, at any point in the process, set the
discussion period to any length between 1 and 3 weeks, except that
they may not do so in a way that causes the discussion period to end
within 48 hours of when this change is made, unless that would
require them to set a discussion time beyond three weeks.

[...]

8. Anyone may propose an extension to the discussion time. These
extensions may be seconded according to the same rules that apply to
second new ballot options.

9. As soon as a time extension has received the required number of
seconds, these seconds are locked in and cannot be withdrawn.

10. When a time extension has received the requ

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --C0kHGrFTnkNCZXXAz15Si0TAFYon7gM7Y
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 10/24/21 2:01 PM, Wouter Verhelst wrote:

6. The project leader may, at any point in the process, set the
discussion period to any length between 1 and 3 weeks, except that
they may not do so in a way that causes the discussion period to end
within 48 hours of when this change is made, unless that would
require them to set a discussion time beyond three weeks.

What is the purpose/intent of the "unless" here? If the discussion
period is coming right up on (< 48 hours) 3 weeks, can the DPL truncate
it using this?

10. When a time extension has received the required number of seconds,
the discussion time is extended to end 72 hours from when the
extension was first proposed.

This wording might need some tweaking for clarity/anti-abuse.
Specifically, if I ask for and receive an "extension" when there was
more than 72 hours left already, what happens?

--
Richard


--C0kHGrFTnkNCZXXAz15Si0TAFYon7gM7Y--

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE1Ot9lOeOTujs4H+U+HlhmcBFhs4FAmF1x9IACgkQ+HlhmcBF hs7CAg/+Phg0rUpcm6GGBQP8L1agZ/73VrZQIh93bh1XJP9z3TnAaCQmNehik4tP QDibuSQjsQMWpd8PW9mx+NwYEWpaDfenxGVklwuj2zLd9JkziA39yi0n54tRjBMw Vzd7k1C3CiJ/Wvu+eYnNzSbIstVBSr3yojc8MkufT9Bf7SAngHPUb1p7wVqCuEt6 bW5gXV7PnkSGQg/Bn26gYzD+ESIl8qN172PJGwqEUEJPWhYQT+7hCY81z7jg2u23 jo6ACoS49tnCJapPAWRiuBFcTOyf97SkkAsvLnBK/TMhZ2/DsdXglTKRbT6B0qcF qzB6cEQ6QHTXvC2BVoA67rhZ7pPyK50ZOMq/oo08EQ65uCnGgQCLGyV6cXEVgpcJ ZHYl/EOjBu6o58TeS/B0OitmE527sduRkcfgQfWR2dO8tOT12AISckC3P+7Chb4C jj6FDMBA+YVjtUSnEhAbYapxu97wXMAv4Q+5UTiLNGhOjWXFys6KH+KwGUQnN8yZ +6dbIi0evFC3RqV4v1mylnkyqoodv1aYpDRCoSbumlyyBcQeXNBci3RjurBI7OgE O69o4efpj0Z5uQuFD0q/55CrCSGPK4Mu46ZqE00VSEJaNfIh0044Uak1zH1i/lyA dbE11IuW7Xy4cUjRkZ8tSdXSx+9+V/6gH5zQUpvsqhQbpJZKQCo=
=l379
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Wouter" == Wouter Verhelst <wouter@debian.org> writes:

Wouter> However, the problem I see with strict timings that cannot
Wouter> be extended in any possible scenario is that we may end up
Wouter> with a situation where one option cannot be fleshed out
Wouter> entirely due to lack of time. I think it's unrealistic to
Wouter> assume that in such a case everyone can be convinced to
Wouter> postpone the vote by two weeks, *at least*, rather than
Wouter> extend the discussion time by a few days in order to allow
Wouter> the option that hasn't finished gathering enough seconds to
Wouter> finish up and become acceptable to enough people.

I think this is interesting to explore.
It's important to me that there be a maximum time that discussions can
last.
But I am open to the idea of being able to extend the discussion time
because you have k seconds interested in doing so even though you don't
yet have a ballot option.

I'll note that under Russ's proposal, you could do this by proposing a
ballot option like
"We'd like to explore mandating using rpm rather than dpkg, but need a
few days to flesh that out. We will replace this ballot option before
the vote, but if somehow we don't, vote for this option if you'd like to
give us a chance to frame that in the next discussion."

That's clunky I grant you, and I'm definitely open to the idea that
rather than proposing a ballot option like that, k people could delay
the clock (but not more than the maximum discussion period) in order to
get an option onto the ballot.

Wouter> So what I think is important is to allow for a way to get a
Wouter> short amount of extra time, *once*, in order to finish up a
Wouter> proposed ballot option.

I think what I propose above gives you that.

Wouter> This could be accomplished as follows:


Wouter> The process can be repeated as
Wouter> long as the discussion time has not expired; but, crucially,
Wouter> anyone who seconded a previous extension request cannot
Wouter> second another one (although you can *request* another
Wouter> extension if you want).

Wouter> In practice this would mean that if you have a significant
Wouter> level of support for extending the discussion time, you can
Wouter> probably get the discussion time extended twice, and *maybe*
Wouter> three times if you're lucky, but I think it highly unlikely
Wouter> you'll be able to extend beyond that.

Interesting:-)
I'd have to think hard about whether to rank that proposal above or
below FD.
I prefer Russ's option, but given your goals I agree this sounds like a
good way to achieve them.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Oct 24, 2021 at 03:53:38PM -0500, Richard Laager wrote:

On 10/24/21 2:01 PM, Wouter Verhelst wrote:

6. The project leader may, at any point in the process, set the
discussion period to any length between 1 and 3 weeks, except that
they may not do so in a way that causes the discussion period to end
within 48 hours of when this change is made, unless that would
require them to set a discussion time beyond three weeks.

What is the purpose/intent of the "unless" here? If the discussion period is coming right up on (< 48 hours) 3 weeks, can the DPL truncate it using this?

It was never my intention to allow the DPL to override a time extension.
I see now that that is indeed not forbidden in my proposal; this is an oversight that I will need to remedy. Thanks for pointing that out.

The wording I use allows the DPL to reduce and then lengthen the
discussion time to any point between one and three weeks.

If the DPL reduced the discussion time to, say, two weeks, and then
through the other process the discussion time is lengthened to 3 weeks
minus a day, then in the time window between 3 weeks minus 48 hours and
when the discussion time is now scheduled to end, the DPL would not be
allowed to lengthen the discussion time again to the maximum of three
weeks. I think that would be suboptimal.

But I realize now that the "causes" in that sentence already covers
that, so I can probably drop that "unless" cause and leave the paragraph
as-is.

10. When a time extension has received the required number of seconds,
the discussion time is extended to end 72 hours from when the
extension was first proposed.

This wording might need some tweaking for clarity/anti-abuse. Specifically, if I ask for and receive an "extension" when there was more than 72 hours left already, what happens?

Two things:

- The DPL will not be able to reduce the discussion time to less than
the 72 hours your extension gives you
- You will not be able to ask or second another extension.

... but nothing beyond that. Specifically, the discussion time will not
be extended beyond the original time, because your extension falls
entirely within the existing discussion period.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Oct 22 2021, Wouter Verhelst <wouter@debian.org> wrote:

I also believe that a ballot with options that were written by people
who do not support that option will usually result in a cluttered
ballot, with various options that are almost but not quite the same
thing, and options that are irrelevant noise and which will never win. I think this behavior should be discouraged if not outright forbidden (although, again, I'm not sure how to forbid them),

How about something like this?

"My proposing or seconding a ballot option, every proposer/amender
commits to rank this option above FD and (in case of multiple ballot
options) higher than at least half of all the options. Should the proposer/amender's ballot not confirm reflect this at the time of the
vote, proposer's/amender's vote will not be counted."


Best,
-Nikolaus

--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

»Time flies like an arrow, fruit flies like a Banana.«

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

hi,

i'm just following along, so please excuse my brief comments from the sidelines...

On Mon, Oct 25, 2021 at 11:15:18AM -0600, Sam Hartman wrote:

Wouter and I are going to disagree on this, but I actually think that
the work I did during the latest systemd vote significantly helped move
the discussion forward. By trying to listen to various sides and trying
to present several options I think I managed to frame the process in a
way that was more constructive.

I'm sure that process can be refined. But I'd rather see DPLs do that
work more rather than less.

I also don't want to see that work restricted to the DPL. In many cases
I'd rather see ballot options drafted by people in the middle rather
than by strong proponents of a polarized position.

actually I'm not so sure I want the DPL to be regularily involved in such activities. Undoubtfully these activities are usefull, but I fear they
might be less useful when done by the DPL...

[this is a generic remark, not based on the systemd vote.]

1) Remember that we want to move toward secret ballots.

Do *we*, really? I'm not sure I like the idea but at least I recall some
people discussing this. Also I'm pretty sure many people^wDebian members have not even heard this being discussed.


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

If you upload your address book to "the cloud", I don't want to be in it.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmF27CAACgkQCRq4Vgaa qhxcQA/9GoIkayzLvd2hNm/XDCjVAyAuXcEVvXV6gunG5Lb2loDGYHxauc4Knbwd 5DUMU9kcPbeyFBlohhhcvhxUJtHuZI6bQ7+3C2kWUdqDeRNhZ/vxcbyuhBAjQpZi OlAGsWdVQe5apoV0CPuxliNdL9d0TNlvzLurgom0ewoNMVz6ulr1HAHxOlb+QTey 1cao2mtQNDFh0o97uVnax2/Xj5NU9xoX4Jmk1gjYIkBv45FY0eAqLnb1irunTsbn uPUP3BGALmYvOT7oyxiFJGK8IhZimOEQ/ZMuvis8Tvq4mk3nsy9ZmpjjyhXyjUCg fkcX2tYZdcJTVLHYHGFjMpzt1GvQixSzR/5/YYrsZ5ZNZ9zZlvQRbpIf54TcIw3s Sd6BBNYH+vT+g1OVoZR+pKlFoWbUf2VdeJxx068dI3n9DW1IlHMtvNQCe9wgQ4f3 eq6o8UwJr/ShGV0faz3ma5i3gSHSqQ698SGLsAPMXwTcYJJh+BhTjiob3j6X5FZi lt4/D5uQbVTfussRaAeTxDDyD0GBYuMbh5ij/EXaGzCtyDRJt1VwCL2mUwTYqwED 6QfpjhM2AyPsZmX2p/ijEVi4ZhHQ1eR5p/LqHbL

"Nikolaus" == Nikolaus Rath <Nikolaus@rath.org> writes:

Nikolaus> On Oct 22 2021, Wouter Verhelst <wouter@debian.org> wrote:
>> I also believe that a ballot with options that were written by
>> people who do not support that option will usually result in a
>> cluttered ballot, with various options that are almost but not
>> quite the same thing, and options that are irrelevant noise and
>> which will never win. I think this behavior should be discouraged
>> if not outright forbidden (although, again, I'm not sure how to
>> forbid them),

Nikolaus> How about something like this?

Nikolaus> "My proposing or seconding a ballot option, every
Nikolaus> proposer/amender commits to rank this option above FD and
Nikolaus> (in case of multiple ballot options) higher than at least
Nikolaus> half of all the options. Should the proposer/amender's
Nikolaus> ballot not confirm reflect this at the time of the vote,
Nikolaus> proposer's/amender's vote will not be counted."

Wouter and I are going to disagree on this, but I actually think that
the work I did during the latest systemd vote significantly helped move
the discussion forward. By trying to listen to various sides and trying
to present several options I think I managed to frame the process in a
way that was more constructive.

I'm sure that process can be refined. But I'd rather see DPLs do that
work more rather than less.

I also don't want to see that work restricted to the DPL. In many cases
I'd rather see ballot options drafted by people in the middle rather
than by strong proponents of a polarized position.


I'll note that it seems very likely that all the options I proposed
would have been preferred to FD. (We don't quite know for sure because Proposal C was withdrawn in favor of Proposal F).

The restrictions you propose would make this sort of framing the
discussion and putting together a slate more difficult, and so I think
it's a really bad idea because I think it takes away one of the tools
that shows promise in reducing conflict in Debian.

Even if you agree with wouter's goal, I think there are a couple of
problems:

1) Remember that we want to move toward secret ballots.
I think your proposal is either impossible to implement with secret
ballots, impossible to verify, or exposes enough information that it
would compromise secrecy. That depends on exactly how the secretary
chose to implement secret ballots and your proposal.

2) Your proposal gets in the way of people changing your mind. In
effect, you're asking people to lock in their positions. That
contributes to the sort of polarization and conflict that I'd like to
see us avoid.

--Sam

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCYXbmJwAKCRAsbEw8qDeG dKtLAQD66uhEc5VHZm1c9Tl9Vp+7mXm6IHS78vB0B2ZUYPqV/gEA0A4ABSpkHggM U2rmax+Z6+YW2g2xhP37DYfFNkByKww=
=sPSY
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Oct 24, 2021 at 08:41:15PM -0600, Sam Hartman wrote:

Interesting:-)
I'd have to think hard about whether to rank that proposal above or
below FD.
I prefer Russ's option, but given your goals I agree this sounds like a
good way to achieve them.

Can you shed some light on your opinion here? I've tried to build an
option that I hope can achieve some form of consensus, and I would like
to know whether I have succeeded in doing so. I don't think I'll change
much if not, but it would be useful information nonetheless.

Thanks in advance,

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Nikolaus,

On Mon, Oct 25, 2021 at 11:20:13AM +0100, Nikolaus Rath wrote:

On Oct 22 2021, Wouter Verhelst <wouter@debian.org> wrote:

I also believe that a ballot with options that were written by people
who do not support that option will usually result in a cluttered
ballot, with various options that are almost but not quite the same
thing, and options that are irrelevant noise and which will never win. I think this behavior should be discouraged if not outright forbidden (although, again, I'm not sure how to forbid them),

How about something like this?

"My proposing or seconding a ballot option, every proposer/amender
commits to rank this option above FD and (in case of multiple ballot
options) higher than at least half of all the options. Should the proposer/amender's ballot not confirm reflect this at the time of the
vote, proposer's/amender's vote will not be counted."

I had considered something along those lines, but decided against it.
Firstly for the same reason that Sam also pointed out: people should be
allowed to change their minds.

Additionally, while I think it is wrong to *draft* an option that you
consider incorrect, I do not consider it wrong to *second* an option
that you consider incorrect. As an example, consider that AJ Towns
seconded GR 2006_005, his own recall vote. I think that was a
reasonable thing to do, and I don't think we should forbid such behavior
by anyone. If you consider that plus the fact that Russ's proposal
allows proposers to withdraw their ballots, then this would incentivize withdrawing proposals that otherwise still have sufficient support,
which is not necessarily a good idea.

So thanks, but no thanks :)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Wouter" == Wouter Verhelst <wouter@debian.org> writes:

Wouter> Can you shed some light on your opinion here? I've tried to
Wouter> build an option that I hope can achieve some form of
Wouter> consensus, and I would like to know whether I have succeeded
Wouter> in doing so. I don't think I'll change much if not, but it
Wouter> would be useful information nonetheless.

Russ's option has a maximum time for discussions.
Yours does not.

However, I think you've done a good job of coming up with counters for
most of the abuses that we thought of here, and so I think it likely
that your option would be a significant improvemement over the status
quo.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sam Hartman <hartmans@debian.org> writes:

"Wouter" == Wouter Verhelst <wouter@debian.org> writes:

Wouter> Can you shed some light on your opinion here? I've tried to
Wouter> build an option that I hope can achieve some form of
Wouter> consensus, and I would like to know whether I have succeeded
Wouter> in doing so. I don't think I'll change much if not, but it
Wouter> would be useful information nonetheless.

Russ's option has a maximum time for discussions.
Yours does not.

Wouter's system exhausts K+1 votes for extending the discussion period
each time it is extended, so technically it does impose a maximum time
assuming that we don't add new developers during the discussion period at
a rate equal to or greater than 6 developers every three days (which seems unlikely). The question is how long that maximum time would be in
practice. This was one of the things that I was curious about and hadn't
taken the time to do some calculations. This message reminded me I wanted
to do that, so I took a moment to do so.

The most concerning scenario from my perspective is if a group that
believes they would lose a GR attempts to postpone it to avoid losing
(perhaps in the hope that by stalling conditions will change). If a
majority of the project wants to stall a GR, that's less concerning. I
think that would still be quite bad for the project if it happened, but I
think it's less likely to happen and the GR would eventually fail anyway,
so that stalling isn't postponing an action the project would then take.

So, let's analyze that case and see how far back a vote could be pushed.

Between the last two GRs and the last two DPL elections, the vote with the largest number of unique voters was 455. Assume for the sake of argument
that we're trying to decide something on which the project is split 60/40.
I'm quite certain that not everyone opposed to a GR would be willing to constantly delay it; suppose that half those opposed are so willing (I
think this is wildly high). That says 20% of the voters would be willing
to support a delay, or 91 people. Assume K is 5, so 6 people are required
for each three day delay. The vote could then be delayed 15 times, or 45
days, so about six and a half weeks on top of an initial three week
discussion period, for a total discussion period of close to ten weeks.

(This is not precisely accurate since the DPL can delay the vote one time without requiring seconds, and the TC can delay the vote one time acting
as the TC separate from acting as individuals, but I think it's safe to
ignore those cases for the purposes of this back-of-the-envelope
analysis.)

This analysis is very sensitive to the percentage of people in the
minority who would be willing to delay the vote. I think a more likely
number (probably still too high) would be at most 10% of the voters (a
quarter of those in the minority), which would allow 7 delays, or 21 days
(3 weeks), for a maximum discussion period of six weeks.

Wouter, I think your proposal would be more attractive to those of us who
are concerned with not allowing a GR to be unnecessarily prolonged if you
would consider closing off that tail risk of a truly excessive delay. If,
for example, you capped the maximum discussion period at six weeks, which
per the above analysis is probably as long as it realistically would be
delayed anyway, it would provide some psychological reassurance that the process can't drag on forever.

I personally would still prefer a maximum discussion period of
substantially less than six weeks and am highly dubious of the benefits
(and quite worried about the harms) of a six week discussion period. I
also think this system makes the voting process more open to procedural manipulation than my proposal (although this is more a gut feeling than anything concrete, and it's arguable), and essentially forecloses the
project's ability to take any timely action without essentially unanimous consensus, so I would still favor my proposal. But it would make me more comfortable with voting this proposal above further discussion.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Russ Allbery wrote:

I also think this system makes the voting process more open to procedural

manipulation than my proposal (although this is more a gut feeling than anything concrete, and it's arguable), and essentially forecloses the
project's ability to take any timely action without essentially unanimous consensus, so I would still favor my proposal.

What about this.
- any developer may request an extension of one week
- the request is granted if L>=K developers second it
- but it is denied if M>=L developers oppose it
- if the DPL seconds or opposes the request, that counts as K votes
(this means that the DPL can get an extension alone if nobody opposes,
but can't force an extension if enough developers oppose)
- the extension must be requested at least 48 hours before the end of
the current discussion period, in order to give opposers enough time
to speak out
- that can be repeated any number of times, or no more than a fixed
number of times, say three

Gerardo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Russ" == Russ Allbery <rra@debian.org> writes:

Russ> This analysis is very sensitive to the percentage of people in
Russ> the minority who would be willing to delay the vote. I think
Russ> a more likely number (probably still too high) would be at
Russ> most 10% of the voters (a quarter of those in the minority),
Russ> which would allow 7 delays, or 21 days (3 weeks), for a
Russ> maximum discussion period of six weeks.

I did less math, but my intuition was the same.
My intuition was that you could probably get six weeks of delay for a GR
that some minority really didn't like.
Beyond that, I guess the political back pressure would be strong enough
to git rid of the delay mechanism after the triggering GR was dealt
with.

I don't think adding a maximum matters to me much because I think that
the practical maximum is somewhere between 6-9 weeks.

I definitely prefer Russ's proposal.

One concrete change I'd request would be language added that said what
the delays should be used for.
Something like "Delays should only be used to provide time to develop additional ballot options and not to delay the vote on a GR that those
seeking a delay find objectionable."
Such language, particularly if phrased with should language, has no
normative effect based on how the constitution defines should.

However, I think it might have behavioral effects in terms of setting
community expectations.
For example I could ask someone what ballot option they were working on
if they proposed a delay.
And if it was clear that they were not, our normal mechanisms for
approaching behavior inconsistent with our norms could be applied.

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCYYLMPgAKCRAsbEw8qDeG dH68AP0a92bFeTihD7WsgiLrm4Otj4sZbvSn4L0yQsoLnI9sfAEAtsViw+HP/SM3 qhTVMRFtqKda/3d4sKpASvZ5ooQa/gY=
=vwqJ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

It looks like discussion of this option has died down, so now is probably
a good time for me to express my personal opinion for why I prefer my
option, now that it hopefully won't skew any of the discussion from
others.

I understand your analysis for why you don't want a fixed time limit on discussion, and I think we're just coming to this with different
assumptions and preferences. What I see in your analysis is a focus on
getting the best ballot options possible and a belief that more discussion leads to better options. I'm dubious this is true (I think this is a
matter of opinion on which we're unlikely to convince each other), and
also don't feel like my personal view is represented in your analysis:
that arriving at a decision in a timely fashion is usually more important
than getting the absolute best options on the ballot, that longer
discussion periods are often destructive to project unity rather than
leading to better decisions, and that long discussion periods increase the burden of anyone who wants to address an issue via GR and therefore lead
to leaving problems unresolved because a GR is too much work.

A lot of the problems I see are deeply embedded and my proposal won't
resolve them all, but I think capping the maximum discussion period is far
more helpful than harmful in arriving at a good decision. I think you may
be underestimating the benefits of a timely process, and overestimating
the benefits of developing another ballot option. I also think that
setting a time limit on how long a GR proposer is expected to participate
in and guide a process will be helpful for allowing more people to be
willing to commit to that work.

Obviously, I could be wrong about these things! But this is where I'm
coming from personally.

As mentioned earlier, I don't think one has to agree with all of my
beliefs about this process to support my proposal. I think it's a
compromise (I'd prefer a shorter starting maximum discussion period
myself), and preserves a lot of the behavior of the existing system rather
than making a more significant change. As mentioned earlier, I don't
think my proposal decreases the maximum length of the discussion process
in most circumstances; it just makes predictable and concrete what's
already implicit in our current system.

In a similar spirit, although your proposal isn't my preference and I'm
quite worried about the deleterious effects of allowing repeated
extensions of the discussion period, I think it's a very interesting
proposal. The approach of exhausting votes for extending the discussion
period hadn't occurred to me, and I think it's a quite elegant way of
avoiding going all the way to a voting system for discussion period
extensions. I'm inclined to support it above further discussion (although
I prefer my proposal).

One thing I did notice when re-reading it: the interaction between the DPL varying the length of the discussion and the extensions seems complicated
and not entirely clear to me, and I'm also not sure I like timing the extensions from the point at which they're sponsored as opposed to
relative to the current discussion period. I wonder if you could make the system even simpler, producing a scheme that has some admirable simplicity advantages over my proposal. Something like this:

1. The discussion period starts when a draft resolution is proposed and
sponsored. The length of the discussion period starts at 1 week.

2. An extension to the discusison period may be proposed and sponsored
according to the requirements for a new resolution. As soon as a
discussion period extension reaches the required number of sponsors, it
takes effect and cannot be withdrawn.

3. The first two times the discussion period is extended add an additional
week to the length of the discussion period. Subsequent extensions add
an additional 72 hours.

4. The proposer and sponsors of an extension to the discussion period may
not propose or sponsor any additional extensions to the discussion
period for the same General Resolution.

5. The discussion period may not be extended beyond six weeks.

and then drop not only the language about extending the discussion period
when the ballot changes but also all the language for the DPL varying the length of the discussion period, and use this system as the only mechanism
for changing the length of the discussion period.

This preserves the same minimum discussion period (1 week), but makes it
very easy to extend it to two weeks and moderately easy to extend it to
three weeks. This will probably happen for all but the most urgent and uncontroversial GRs. It also entirely avoids the problem (still present
in my proposal) of the DPL having to make an often-politicized decision
about varying the discussion period.

(I also agree with Sam's comment that a note about when an extension of
the discussion period is appropriate would probably be useful, although I
did not attempt to incorporate that into this proposal.)

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sun, Nov 7, 2021 at 3:53 PM Russ Allbery <rra@debian.org> wrote:

makes it very easy to extend it ....
This will probably happen for all but the most urgent and
uncontroversial GRs.

Didn't we just see the opposite? In the most recent referendum, the
decisive argument for shortening was the existence of hardened fronts
rather than a lack of controversy. Sam suspected that people had made
up their minds. [1]

The DPL later cited urgency, but did so without an explanation and in
an apparent attempt to end the fighting quickly. [2] The vote was
urgent only because it threatened to tear the community apart.

The outcome was close, too—and anything but uncontroversial.

Kind regards
Felix Lechner

[1] https://lists.debian.org/debian-vote/2021/03/msg00106.html
[2] https://lists.debian.org/debian-vote/2021/03/msg00115.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Felix Lechner <felix.lechner@lease-up.com> writes:

On Sun, Nov 7, 2021 at 3:53 PM Russ Allbery <rra@debian.org> wrote:

makes it very easy to extend it .... This will probably happen for all
but the most urgent and uncontroversial GRs.

Didn't we just see the opposite?

I don't understand the question. This statement is in the context of
Wouter's system for extending the discussion period via a proposal and sponsors. That system does not currently exist, and therefore this could
not have happened or not happened in any previous GR.

In the most recent referendum, the decisive argument for shortening was
the existence of hardened fronts rather than a lack of controversy. Sam suspected that people had made up their minds. [1]

In the most recent referendum, the DPL shortened the discussion period,
which the current constitution gives the DPL the power to do. The
proposal to which you're responding is to drop that provision entirely in
favor of Wouter's system for deciding on extensions of the discussion
period. That modification of Wouter's system does not have any mechanism
for *shortening* the discussion period (instead, it starts at one week and
can only be lengthened), so no argument for shortening would even be
relevant in that system.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sun, Nov 7, 2021 at 5:13 PM Russ Allbery <rra@debian.org> wrote:

I don't understand the question.
That system does not currently exist, and therefore this could
not have happened

Without wanting to take up too much bandwidth, I believe that
deductive logic misses key insights. [1]

More broadly, you are not the only one who thinks I have strange
feathers. I mean, what is this guy talking about? He has so much to
learn! Perhaps this short video [2] can shed some light on how two
parties might examine the same subject from two sides. In some form,
it will solve Debian's social issues.

Kind regards
Felix Lechner

[1] https://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems
[2] https://www.youtube.com/watch?v=LltoUg_WL2k

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Felix Lechner <felix.lechner@lease-up.com> writes:

On Sun, Nov 7, 2021 at 5:13 PM Russ Allbery <rra@debian.org> wrote:

I don't understand the question. That system does not currently exist,
and therefore this could not have happened

Without wanting to take up too much bandwidth, I believe that deductive
logic misses key insights. [1]

More broadly, you are not the only one who thinks I have strange
feathers. I mean, what is this guy talking about? He has so much to
learn! Perhaps this short video [2] can shed some light on how two
parties might examine the same subject from two sides. In some form, it
will solve Debian's social issues.

My response was not intended as a critique of your way of thinking. I
really did mean my response literally: I don't understand your question.
That makes it hard for me to respond to it, or to take into account any
key insights that it contains.

I tried to explain why I didn't understand the question. Maybe you could
try rephrasing in the hope that I may understand a different version of
the question better?

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Mon, Nov 8, 2021 at 7:43 AM Russ Allbery <rra@debian.org> wrote:

Maybe you could
try rephrasing in the hope that I may understand a different version of
the question better?

The question did not have an answer. [1] To avoid pain, the project
prefers shorter discussions on controversial topics. It is the
opposite of what you wrote.

Secret votes will reduce fear, but for a wholesome remedy contributors
have to forgo provocation and punishment and instead seek compromise
and common ground. Both will lead to a lasting peace.

Kind regards
Felix Lechner

[1] https://en.wikipedia.org/wiki/Rhetorical_question

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Felix Lechner <felix.lechner@lease-up.com> writes:

The question did not have an answer. [1] To avoid pain, the project
prefers shorter discussions on controversial topics. It is the opposite
of what you wrote.

I think the detail that you may be missing is that under Wouter's system
for extending the discussion period, it doesn't matter what the project as
a whole wants. The extension is not decided by vote; opposition is not counted. Rather, any six (K+1) Developers can extend the discussion
period, regardless of anyone else's opinion of whether that's a good idea.

What I wrote, which kicked off this subthread, was:

This preserves the same minimum discussion period (1 week), but makes
it very easy to extend it to two weeks and moderately easy to extend
it to three weeks. This will probably happen for all but the most
urgent and uncontroversial GRs.

I believe it is correct to say that, should we adopt a system such as that modification of Wouter's proposal, one will be able to find at least 6 Developers to extend the discussion period two two weeks for all but the
most urgent and uncontroversial GRs, and that it is highly likely that one
will be able to find 12 Developers to extend it to three weeks. It's a
very low bar of support: about 3% of the voting membership to extend to
three weeks. As we've seen in the discussion, some folks believe the discussion period should be longer for (nearly) all votes as a matter of principle, and would presumably routinely support such an extension.

That proposed system may still be a bad idea, to be clear. I think it
provides a rather dramatic simplification of the discussion period length
over either my proposal or Wouter's original proposal (and over the
existing constitution), which has a lot of appeal at least to me. (All
things being equal, I think simpler systems are better than more complex systems.) But it does place a burden on people to propose an extension
for any GR whose discussion period should be longer than a week, which may
not be desirable.

If your point is, instead, that Wouter's general system is undesirable
because it allows the discussion period to be extended longer than the
project as a whole may wish discussion periods extended, since the project
as a whole may prefer shorter discussions on controversial topics, well,
yes, I largely agree, which the root of why I prefer my original proposal
over Wouter's.

To add some more detail to that, I think there is a trade-off. Longer discussion periods do produce better proposals and a richer variety of
options, plus are simply better from a democratic perspective since they
give people more time to become aware of the proposal and to think about
it in detail. But I think we can all agree that there is a point of diminishing returns (although we may disagree about where that point is).

For example, making the discussion period of every GR take a minimum of
one year would probably produce better-crafted final results (I do know of
one organization whose bylaws work this way), but I don't think that's
what we want. It sacrifices timeliness and it requires anyone who wants
to make a change sign up for an extended effort.

Also, for Debian, the other aspect of the trade-off is that, for
controversial GRs, the pattern has been that the discussion gets more
heated and divisive as it goes on. People start repeating themselves,
they get angrier that no one is changing their mind, the messages get more personal, and I felt like I could watch people's views become more
entrenched and less generous to those with whom they disagreed. So I
believe there is also some harm that is done by extended discussion
periods, and we have to balance that against the benefit achieved by
having better proposals and more time for people to absorb the proposal.

My proposal (not the modification of Wouter's but the one that I'm
bringing to GR) chooses to strike that balance by putting it at roughly
the same place the balance lies today with the existing system (the
current minimum is two weeks and for recent controversial GRs we've gone
three weeks), but making that timing more predictable so that people have
clear deadlines to work towards and the timing of the vote isn't as
susceptible to strategic maneuvering. It's not a very ambitious change;
it probably shortens the formal discussion period a bit on average, but
not a lot.

My theory is that we're probably not too far off from the right balancing
point in that trade-off right now, and the DPL retains the ability to vary things by a week in either direction if, for a given GR, they believe that
the balance isn't quite right. My theory is also that three weeks is a sufficiently long time to absorb a proposal and come up with a
counter-proposal if everyone knows there is a deadline, so that the
original GR proposer doesn't have an unfair advantage.

One certainly may disagree with those theories! I believe Wouter does,
and hence his alternate proposal, which addresses this trade-off in a
different way.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi

On Mon, Nov 8, 2021 at 9:49 AM Russ Allbery <rra@debian.org> wrote:

If your point is, instead, that Wouter's general system is undesirable
yes, I largely agree

Without reflecting on either proposal, I merely cautioned that
constitutional amendments should be based on sound premises.

As to the point between you and Wouter, is there perhaps a simpler
measure when a discussion is over—such as one week without a proposal
that attracted at least three novel supporters (in total)?

Kind regards
Felix Lechner

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Felix Lechner <felix.lechner@lease-up.com> writes:

On Mon, Nov 8, 2021 at 9:49 AM Russ Allbery <rra@debian.org> wrote:

If your point is, instead, that Wouter's general system is undesirable
yes, I largely agree

Without reflecting on either proposal, I merely cautioned that
constitutional amendments should be based on sound premises.

...okay? I truly don't understand why you felt moved to caution me about
that, but sure, I agree with that principle. I believe my constitutional amendment is based on sound premises; if I didn't, I wouldn't have made
it. :)

As to the point between you and Wouter, is there perhaps a simpler
measure when a discussion is over—such as one week without a proposal
that attracted at least three novel supporters (in total)?

I think this is functionally equivalent to Wouter's proposal except even
weaker (you've replaced 6 with 3), so I would prefer Wouter's proposal to
that one.

I suppose the counter-balance is that you say "proposal," by which I
assume you mean ballot option, so each group wanting to delay further has
to produce a concrete proposal, but that makes me less comfortable with it because it creates an incentive to essentially "spam" the ballot with
proposals in order to achieve the desired goal of extending the discussion period. Wouter's proposal seems better since it allows people to ask
directly for what they want (a delay) without having to work around the
spirit of the rules to achieve it.

This is also an advantage of Wouter's proposal over mine: my system also creates an incentive to add a ballot option only to extend the discussion period. That's also not ideal; I just couldn't see a way of avoiding it without adding what felt like too much complexity. In my system, that extension is limited to (normally) an additional week (the intent is to
give people some time to absorb the implications of a new proposal), so I
think the incentive for new ballot options as a procedural maneuver rather
than a true option is lesser and probably won't be an issue in practice.
I also wanted to allow addition of a placeholder option that could be
fleshed out later, and this seemed the simplest way to do that.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dear all,

I am interested in this informal proposal from Russ, which has not
received much explicit feedback:

On Sun 07 Nov 2021 at 03:53PM -08, Russ Allbery wrote:

I wonder if you could make the system even simpler, producing a scheme
that has some admirable simplicity advantages over my proposal.
Something like this:

1. The discussion period starts when a draft resolution is proposed and
sponsored. The length of the discussion period starts at 1 week.

2. An extension to the discusison period may be proposed and sponsored
according to the requirements for a new resolution. As soon as a
discussion period extension reaches the required number of sponsors, it
takes effect and cannot be withdrawn.

3. The first two times the discussion period is extended add an additional
week to the length of the discussion period. Subsequent extensions add
an additional 72 hours.

4. The proposer and sponsors of an extension to the discussion period may
not propose or sponsor any additional extensions to the discussion
period for the same General Resolution.

5. The discussion period may not be extended beyond six weeks.

and then drop not only the language about extending the discussion period when the ballot changes but also all the language for the DPL varying the length of the discussion period, and use this system as the only mechanism for changing the length of the discussion period.

I have been studying Wouter's formal proposal and believe that the only substantive difference with the quoted text is that where the quoted
text has a hard limit on the discussion period, Wouter's proposal
instead has a mechanism for objecting to further extensions.

Would someone else be able to confirm this reading, please?

If I'm right, I am considering proposing a third choice which is
identical to Wouter's, except it would drop the mechanism for objecting
to extensions beyond four weeks and reimpose a maximum discussion
period, which I am thinking of setting to four weeks.

I think this is a good middle ground between the two proposals we have
so far. This third proposal

- is procedurally simple

- incorporates Russ's concern about overly long discussion periods, with
a maximum that is only a little bit longer than his

- incorporates the idea that three weeks is very short in Debian terms

- should still allow the project to respond quickly when we mostly agree.

Many thanks to Russ and Wouter for all their work on this.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmGlJXUZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQBtvD/95w6BvP1SIwmEZu4sxg1YG UHjGUt2HDEGawTBSBV8fCpJJwiWRHNAoKpkNThEt0oFlnBiZB8pRPujnrABXPek8 oqwxOgGJyRGJGudBthtX3ngIYyBSCYwF/HFaYrFoESFL4ypgi/gWazJQgBzz3pLE t3ppcBBf+G7VnZqo9HwN4P6oguepwuf1MncARxqOubTMul5dElIZIr3p4OHsZM2R qwh1KYcBT3RrxGz1enRb6J1fZyaNJm2nFsYRhPIGwwN/UlQtF73Dx+KYHsGinM1J uT2SUGkq7JCXR2EHuhTc2XRx2B74dXcXwMs365WUDv5tDHs6wNaDtSQE9NrsPlUA U3sNb06CDjJ2ebptqEAyJK0fmqCAgwWb8Gb+y2yS+tnlfKCiYVFMQLMZ/ToOYbZ2 X0k8uvF4mO70Nu7/aFOXitW4L2d2+J7C64G09I+BJLkHVJBEHWRfe0ZY+1KqgqAW +2N1+3avvc3yhUKjvlB/8ZqwoXdHU/2h+LCy8Z3ZJBwvQ2GTjhv/Qy/mdwds71+K C1lOb2uzW/lS/ycWf8AiHcXktmvNlgGH/JbOb+NBm6/jgz7HcCa6elGrRZd3h/Uu 7LJ9lYOxtTii1pW/cYncSVPzhAQTb+cyFhls8oy1O5PInEfmOut5RBdSJJHmy5Fb rgpUxOwVJdkbcXV1x7T9rg==YQoJ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us

Hi Sean,

On Mon, Nov 29, 2021 at 12:09:41PM -0700, Sean Whitton wrote:

Dear all,

I am interested in this informal proposal from Russ, which has not
received much explicit feedback:

On Sun 07 Nov 2021 at 03:53PM -08, Russ Allbery wrote:

I wonder if you could make the system even simpler, producing a scheme
that has some admirable simplicity advantages over my proposal.
Something like this:

1. The discussion period starts when a draft resolution is proposed and
sponsored. The length of the discussion period starts at 1 week.

2. An extension to the discusison period may be proposed and sponsored
according to the requirements for a new resolution. As soon as a
discussion period extension reaches the required number of sponsors, it
takes effect and cannot be withdrawn.

3. The first two times the discussion period is extended add an additional
week to the length of the discussion period. Subsequent extensions add
an additional 72 hours.

4. The proposer and sponsors of an extension to the discussion period may
not propose or sponsor any additional extensions to the discussion
period for the same General Resolution.

5. The discussion period may not be extended beyond six weeks.

and then drop not only the language about extending the discussion period when the ballot changes but also all the language for the DPL varying the length of the discussion period, and use this system as the only mechanism for changing the length of the discussion period.

I have been studying Wouter's formal proposal and believe that the only substantive difference with the quoted text is that where the quoted
text has a hard limit on the discussion period, Wouter's proposal
instead has a mechanism for objecting to further extensions.

Would someone else be able to confirm this reading, please?

Yes, that's pretty much correct; my current proposal was created after I discarded Russ' informal proposal that you point to here as "not good
enough for me", and then I added the objection mechanism to cope with
that.

If I'm right, I am considering proposing a third choice which is
identical to Wouter's, except it would drop the mechanism for objecting
to extensions beyond four weeks and reimpose a maximum discussion
period, which I am thinking of setting to four weeks.

You may of course do so, but I think it creates a system that
incorporates the worst of both worlds. My proposed system allows one to
extend the time at all time (while making it progressively harder as
time goes on), because I believe it is better to have a system that
allows that flexibility when necessary than to have a system with a
rigid, unchangeable limit.

If you *do* prefer that limit, then I think it makes more sense to have
a system like Russ's, where time is extended when a ballot option is
added, but not past your time limit. His system is procedurally much
simpler than mine, but has the downside that it creates what I think is
an unacceptable hard limit. If you believe three weeks is too short,
might it not be better to propose a system like Russ's, but with the
hard limit at four weeks rather than three?

I don't really like the procedural complexity that my system creates,
but I think that disadvantage outweighs the disadvantage that the rigid
limit in Russ's proposal creates.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Wouter,

On Mon 29 Nov 2021 at 10:34PM +02, Wouter Verhelst wrote:

You may of course do so, but I think it creates a system that
incorporates the worst of both worlds. My proposed system allows one to extend the time at all time (while making it progressively harder as
time goes on), because I believe it is better to have a system that
allows that flexibility when necessary than to have a system with a
rigid, unchangeable limit.

If you *do* prefer that limit, then I think it makes more sense to have
a system like Russ's, where time is extended when a ballot option is
added, but not past your time limit. His system is procedurally much
simpler than mine, but has the downside that it creates what I think is
an unacceptable hard limit. If you believe three weeks is too short,
might it not be better to propose a system like Russ's, but with the
hard limit at four weeks rather than three?

I don't really like the procedural complexity that my system creates,
but I think that disadvantage outweighs the disadvantage that the rigid
limit in Russ's proposal creates.

Belated thank you for your feedback.

No-one else has spoken up in a way which suggests they'd second my
proposal, so I'm not going to pursue it.

If Russ's proposal is the one we end up adopting, one possibility is
that we have another GR simply to increase the limits a bit, after we've
had some experience working within the new procedure.

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmHCaeoZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQJEBEACP1reMZa4xmtCWbbg5Mcpa Jwh8qnScdrbrYXpNaiM+g35eOMDcOMikbkv1U2yKuJvF658lNQa1lQSNB/Df1QRf XRrgA5vvG0R9yYYEP6OsKq63fTAigrIbzz6VUcrq/UNtyg57LitGZNl3zutqo9RU JhKDdruoIgDAAx8A0FSNWzabbXETW/38a38KNKOS2ofPmlunSqkEIaas9oJ7dbsh 8A7iWwGiMBifmExwagtyS240WxpPaPfI9UHqwO20MOW2l5VILd4fu7RjtILutHrY 2fqAKTmdSOfvqCM+ka9vcZ6Iubr+q7rxezq6CFA02BI753GqkQ0S/iowH25R97B9 jkETmIVXSr9Qqch+En1dQ3CTwd8lQDpKwTLOkV0vy3iI9Yk9Gjdkt4WKCVoNopEQ IDhi4IbX2bi4deCxGKisrUtk/K34P/yiZmlx9tXAcyZU77htAf7OJVXxJtEP5vOj Sg0VrlqHRbZMO+qKdYOCr8mC55gx5FsxkBDGLoON77+FoyuLi4GF5DDYVNJfHqDo wcDRL7C/PZnkfxXEVwwkQsoyxCI3AlEuCs9jmzbD2eSNHTrsa8gD69XpP3FKuLIX H3eLnz7opPhdHpGIWneR3L/6xcMVZBPDNuuJOHtBlEnhPDWMkvS1k0C8jybbpAvM XZnSqMtS7kmS26/A4FkjHQ=�CZ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usen