• My position, and possible changes to my proposed system

    From Wouter Verhelst@21:1/5 to All on Mon Nov 15 12:50:01 2021
    Hi all,

    I just caught up with all the traffic on this list (and there were a lot
    of them). Rather than trying to find all the relevant emails and reply
    to each of them individually, let me just combine all my comments in
    this mail.

    First, let me clarify my position: I feel that our voting system works
    best if all the relevant options are represented on the ballot. This
    requires that all relevant options have a chance to be developed; if we
    have a system that has a hard time limit, no matter where it is set,
    then there is a chance that a relevant option would not appear on the
    ballot, which I think should be avoided as it can call into question the legitimacy of the ballot: if a controversial option favoured by a vocal minority was not represented on the ballot, the GR is not likely to
    resolve the issue, because you can be sure that minority will hammer on
    the missing option in the discussion after the GR.

    I realize that this is an edge case, but rules such as the one for our
    voting system should consider all edge cases.

    As such, I think that as long as a reasonable need exists for the
    discussion period to be extended, it should be possible in theory for
    this to be possible. Even if I agree that six weeks is exorbitantly
    long, I am wary of adding a rule to my proposed system that caps the
    discussion time anywhere.

    That being said, I am not unsensitive to arguments of process abuse and diminishing returns, and as such I do believe that extending the
    discussion period should be made harder as time goes on. My current
    proposed system already does that to some extent, but it is certainly
    possible to improve in that area. I had a few other things that I had
    thought of but that, in the interest of not overcomplicating the
    process, I did not add to my original proposal; however, two of them
    (variable extension times and objections to extensions) have now been independently proposed by other people, so I think perhaps I should add
    them after all.

    Additionally, my original proposal had the time extension start from the
    point where it was proposed, rather than from the end of the current
    discussion period. The reason for this was to encourage that extensions
    are only proposed and seconded when they would actually be needed,
    rather than proactively by people who actually care only about avoiding
    the vote at all, but I think we can also avoid that issue by mandating
    that a time extension can only be proposed if there are less than 48
    hours left in the discussion time currently.

    Given all that, here's something that could work, and that I would see
    as reasonable:

    - The initial time of the discussion period is 1 week
    - When less than 48 hours remain in the discussion time, time extensions
    can be proposed under the same rules as ballot option proposals.
    - As soon as a time extension reaches its required number of seconds, it
    is active and cannot be withdrawn.
    - The initial two time extensions increase the discussion time by one
    week; further extensions increase the discussion time by 72 hours
    - Once the discussion time has reached 4 weeks, further extension
    proposals can be objected to by any developer. If the number of
    opposing developers is higher than the number of valid seconders for the
    extension proposal by the time the discussion period would run out if
    the time extension had not been voted upon, then the time extension
    does not happen.
    - If a time extension happens, the proser and the first K seconders can
    no longer propose or second any time extension.
    - There is no limit to objections to time extensions.

    This makes it trivially easy to extend to 3 weeks, not so easy but
    doable to extend to 4, and probably highly unlikely to extend beyond
    that, except if a majority of the project believes that it is better to
    wait a few days than it is to go to a vote now, or to withdraw the vote entirely (and that is the whole point of this process).

    The third option I had in mind (linking a time extension to a particular
    ballot option proposal) had a number of edge cases that meant I thought
    it a pretty bad idea overall, so I'm not going to suggest that.

    The downside of the above as compared to other proposals is that the
    system becomes more complicated with each rule that gets added. I don't
    think it is critically problematic yet with the above proposal, but am
    open to arguments otherwise.

    I note that both Russ and Sam have mentioned they may vote my proposal
    above FD, which I find encouraging. In the interest of clarity, however,
    I'll note that I do not intend to return the favour; I think having a
    time limit that is reflective of the situation at hand is a much better situation than having a set of rigid rules that cannot be changed, other
    than by restarting the whole process from scratch, which is a much worse situation -- I can imagine it being difficult to convince all proposers
    of ballot options that they should withdraw their ballot option so that
    the discussion time can be reset, in case someone just needs a few more
    days of extra time. I think this is important enough that I would rather
    keep the current system instead of moving to the proposal.

    On another note,

    I note that Russ's proposal does not change §5.1.5 (Project Leader -
    Powers - "Propose draft General Resolutions and amendments."). Since we
    now will start referring in appendix A to draft options as "proposals"
    and those who propose them as "proposers", it may be best, in the
    interest of confusion, to also change §5.1.5 to be more explicit about
    the fact that proposals from the DPL do not require any seconds.

    I welcome any thoughts and comments.

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

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

    iQIzBAABCgAdFiEEm2n98/DaCUgGYSn3LfxRmVQYEpYFAmGSR98ACgkQLfxRmVQY EpaE2w//QKZFDVFsRht+GS7WP0yM48Hlu4DRM6WFzbHYNBP2k8iC+IhkEohR68K0 vQ0xEVexC53qg6ULmmbtEhtA8pX1NTAVo0reyt9H2ZfT1JHYrWU5WirsxkGnV9g9 iAqSwqUjFZOkoSxH1X/wE0i2Ace8iYDAxVAfPDi+tlXGqu+ePJvSmDTgXGA6FC2c staaS/zhdEosCGDm6xUDzudO8S92kdl50furPg1LjJZDOfRKAQYjMgDY0NzJKT25 rjqk7YtTtBaRSkly+IG1sOHdOwOULXzvscVwjV2OCVk9/1LmQkgfyLFcHFTq1y4N ETiIBrK5a/U+BlVjyHPDf+PCzXt/cdqzvvm3gY/K1uUL63VSlVRTDT+6ntYcfQ15 rMYvaOiUbNfWJZEcMOhMPGCmxj5JOrg3+VECsk6iVZZzIxMZHbwF9+xj1lJs1SC2 XATC6l7Zjv7VpNRSrmSk/gjB3IJuXjcvyITuApeAm/waEXmKwVljcew5+LaZegZd qVM8rApZ4L4jK7EYUDEOlRksUb7tPSsrSHM+icAXxFx5ukdXsW8Drw4m1RndDTjj 01EkhlARLgdMKgZj3WcHWxGbQJKwYxSUBqMDRS7QKapCxcZDABp9wDJLG31eltmh 1Q0nV6tqGZcyrZUmAUixd0nbLWZ0xKTudZyHCUiMCYRVS7ktki8=
    =Nc+W
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Wouter Verhelst on Mon Nov 15 19:10:01 2021
    Wouter Verhelst <wouter@debian.org> writes:

    First, let me clarify my position: I feel that our voting system works
    best if all the relevant options are represented on the ballot. This
    requires that all relevant options have a chance to be developed; if we
    have a system that has a hard time limit, no matter where it is set,
    then there is a chance that a relevant option would not appear on the
    ballot, which I think should be avoided as it can call into question the legitimacy of the ballot: if a controversial option favoured by a vocal minority was not represented on the ballot, the GR is not likely to
    resolve the issue, because you can be sure that minority will hammer on
    the missing option in the discussion after the GR.

    I think this is a good summary of our core disagreement.

    In contrast, I believe that

    * adding more ballot options quickly reaches a point of diminishing
    returns after the first couple of weeks, after which it does little to
    reduce the controversy of the vote (in fact, it may increase the
    controversy due to the extension of the discussion);

    * having more ballot options is helpful to a point in increasing the
    legitimacy of the outcome, but some people are going to object to the
    legitimacy of any controversial vote and, if we choose to take much
    longer and develop more ballot options, those complaints will shift to
    questioning the legitimacy because the process took so long that people
    stopped paying attention or the ballot is so confusing that we can't
    trust people's votes (we already see those complaints today in a system
    with a roughly equivalent deadline to what I'm setting); and

    * what is lost in the meantime is representation for the people who
    believe that reaching a decision in a timely fashion is significantly
    more important than crafting ballot options for every position.

    My goal is to strike a balance between providing enough time for people to think carefully about the propose and produce additional options, and
    having the process resolve on a timely and predictable time scale such
    that it's not a horrific ordeal and it's conceivable that if we don't like
    the outcome we could vote on it again.

    I do think my concerns apply primarily to more controversial issues, and
    some things, such as constitutional amendments like this one that require
    broad project consensus, may require more time to discuss properly. But I don't think that has to be handled directly in the formal timing; instead,
    one can have a draft discussion such as the one we're having right now and
    only start the process once that's complete.

    I know that you're concerned with someone pre-emptively starting the
    process in the middle of such a discussion. I'm not, because I think
    that's how the system represents the interests of people whose objection
    is not to the text but that we're taking too long to make the necessary decision, and because, particularly for constitutional and other
    super-majority votes which require the most care, a too-early GR can
    easily be voted down while the more thoughtful one continues on its
    original schedule (which is not modified by someone else bringing another
    GR earlier).

    I think we agree on a lot of other things, and I appreciate your
    adaptation of your proposal to try to make it more of a compromise! But I
    do think we have a core disagreement on these points and probably won't convince each other entirely.

    I think I'm convinced that your proposal limits the discussion period sufficiently that it won't cause *too* much damage, but I do think my
    approach would be better for the project as a whole. I'm happy to put
    that disagreement to the project and see how people vote.

    Additionally, my original proposal had the time extension start from the point where it was proposed, rather than from the end of the current discussion period. The reason for this was to encourage that extensions
    are only proposed and seconded when they would actually be needed,
    rather than proactively by people who actually care only about avoiding
    the vote at all, but I think we can also avoid that issue by mandating
    that a time extension can only be proposed if there are less than 48
    hours left in the discussion time currently.

    I'm still not a huge fan of starting the time extension from the point
    when it was proposed because I think it adds a fair bit of unnecessary complexity to figuring out exactly when the discussion period ends. If everything is based on the original proposal, the Project Secretary can
    state the official timing of the original proposal and then all other
    deadlines are easily derived from that. I'm leery of creating a situation where we have to have an argument about email Date headers versus Received headers or something else similarly tedious. (Some of this applies for
    any deadline, I realize, but I think this might make it worse.)

    - Once the discussion time has reached 4 weeks, further extension
    proposals can be objected to by any developer. If the number of
    opposing developers is higher than the number of valid seconders for the
    extension proposal by the time the discussion period would run out if
    the time extension had not been voted upon, then the time extension
    does not happen.

    This is an interesting way of handling voting on extensions. I'm not sure
    what to think of it; voting on the mailing list feels like it may be
    chaotic, and I'm not sure the Project Secretary is going to enjoy the
    counting process, but it does have the merit of not introducing a new
    system.

    On another note,

    I note that Russ's proposal does not change §5.1.5 (Project Leader -
    Powers - "Propose draft General Resolutions and amendments."). Since we
    now will start referring in appendix A to draft options as "proposals"
    and those who propose them as "proposers", it may be best, in the
    interest of confusion, to also change §5.1.5 to be more explicit about
    the fact that proposals from the DPL do not require any seconds.

    Thank you, good catch. I have now added:

    Section 5.1.5
    -------------

    Replace in its entirety with:

    Propose General Resolutions and ballot options for General
    Resolutions. When proposed by the Project Leader, sponsors for the
    General Resolution or ballot option are not required; see §4.2.1.

    to my draft.

    There were also two other places (in 4.2.5 and 6.3.3) where "amendments"
    needed to be changed to "ballot options." I've added those to my draft GR
    as well.

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

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