• Draft proposal for resolution process change (v2)

    From Russ Allbery@21:1/5 to All on Wed Oct 6 06:20:01 2021
    The first round of discussion seems to have died down, and I've made a
    bunch of changes, so now seems like a good time to post the current
    version and encourage more discussion.

    I'm somewhat surprised that there has been no discussion of the timing of
    the GR discussion period, which I expected to be more controversial. The scheme I'm proposing is relatively complex but allows the discussion
    period to vary from 1 week to 4 weeks based on how much ballot option
    activity there is and based on DPL actions. If anyone is unhappy with
    that (if, for example, you think it's too complex or 4 weeks is too short
    or too long), now would be a good time to bring that up so that we can
    discuss it.

    Even if you want to do someething entirely different that you don't think
    I would agree with, I think it's worthwhile to hammer out other ballot
    options now so there's lots of opportunity for discussion and
    proofreading.

    Also, a reminder that these changes will require a 3:1 majority. My goal
    is to get as close to unanimous consensus for these changes as I can get.
    I think the worst outcome would be to go all the way through a GR and find
    that the change has 2:1 support but not 3:1 for reasons that never came up
    or that I didn't have time to address.

    Therefore, if anyone would not support the current proposal, and
    particularly if you would vote it below further discussion, I would love
    to hear from you, either here or in direct email if you would prefer.
    Even if your objections are hazy, I'd love to talk about them and see if I
    can understand and address them.

    Here is my current draft:


    4.2. Procedure

    [...]

    4. The Project Leader has a casting vote. There is a quorum of 3Q. The
    default option is "None of the above."

    [...]


    6.1. Powers

    [...]

    7. [...] There is no casting vote. If there are multiple options with no
    defeats in the Schwartz set at the end of A.6.8, the winner will be
    randomly chosen from those options, via a mechanism chosen by the
    Project Secretary.

    [...]


    6.3. Procedure

    1. Resolution process.

    The Technical Committee uses the following process to prepare a
    resolution for vote:

    1. Any member of the Technical Committee may propose a resolution.
    This creates an initial two-option ballot, the other option being
    the default option of "Further discussion." The proposer of the
    resolution becomes the proposer of the ballot option.

    2. Any member of the Technical Committee may propose additional ballot
    options or modify or withdraw a ballot option they proposed.

    3. If all ballot options except the default option are withdrawn, the
    process is canceled.

    4. Any member of the Technical Committee may call for a vote on the
    ballot as it currently stands. This vote begins immediately, but if
    any other member of the Technical Committee objects to calling for a
    vote before the vote completes, the vote is canceled and has no
    effect.

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

    6. If a vote is canceled under point 6.3.1.4 later than 13 days after
    the initial proposed resolution, the vote specified in point 6.3.1.5
    instead starts 24 hours after the time of cancellation. During that
    24 hour period, no one may call for a vote.

    2. Details regarding voting.

    Votes are decided by the vote counting mechanism described in A.6.
    The voting period lasts for one week or until the outcome is no
    longer in doubt assuming no members change their votes, whichever is
    shorter. Members may change their votes until the voting period ends.
    There is a quorum of two. The Chair has a casting vote. The default
    option is "Further discussion."

    When the Technical Committee votes whether to override a Developer who
    also happens to be a member of the Committee, that member may not vote
    (unless they are the Chair, in which case they may use only their
    casting vote).

    [...]

    7. Proposing a general resolution.

    When the Technical Committee proposes a general resolution or a ballot
    option in a general resolution to the project under point 4.2.1, it may
    delegate the authority to withdraw, amend, or make minor changes to the
    ballot option to one of its members. If it does not do so, these
    decisions must be made by resolution of the Technical Committee.


    A.0. Proposal

    1. The formal procedure begins when a draft resolution is proposed and
    sponsored, as required. A draft resolution must include the text of
    that resolution and a short single-line summary suitable for labeling
    the ballot choice.

    2. This draft resolution becomes a ballot option in an initial two-option
    ballot, the other option being the default option, and the proposer of
    the draft resolution becomes the proposer of that ballot option.


    A.1. Discussion and amendment

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

    2. A new ballot option may be proposed and sponsored according to the
    requirements for a new resolution.

    3. The proposer of a ballot option may amend that option provided that
    none of the sponsors of that ballot option at the time the amendment is
    proposed disagree with that change within 24 hours. If any of them do
    disagree, the ballot option is left unchanged.

    4. The addition of a ballot option or the change via a amendment of a
    ballot option changes the end of the discussion period to be one week
    from when that action was done, unless that would make the total
    discussion period shorter than the minimum discussion period or longer
    than the maximum discussion period. In the latter case, the length of
    the discussion period is instead set to the maximum discussion period.

    5. The proposer of a ballot option may make minor changes to that option
    (for example, typographical fixes, corrections of inconsistencies, or
    other changes which do not alter the meaning), providing no Developer
    objects within 24 hours. In this case the length of the discussion
    period is not changed. If a Developer does object, the change must
    instead be made via amendment under point A.1.3.

    6. The Project Leader may, at any point in the process, increase or
    decrease the minimum and maximum discussion period by up to 1 week from
    their original values in point A.1.1, 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. The length of the discussion period is then
    recalculated as if the new minimum and maximum lengths had been in
    place during all previous ballot changes under points A.1.1 and A.1.4.

    7. The default option has no proposer or sponsors, and cannot be amended
    or withdrawn.


    A.2. Withdrawing ballot options

    1. The proposer of a ballot option may withdraw. If they do, new proposers
    may come forward to keep the ballot option alive, in which case the
    first person to do so becomes the new proposer and any others become
    sponsors if they aren't sponsors already. Any new proposer or sponsors
    must meet the requirements for proposing or sponsoring a new
    resolution.

    2. A sponsor of a ballot option may withdraw.

    3. If the withdrawal of the proposer and/or sponsors means that a ballot
    option has no proposer or not enough sponsors to meet the requirements
    for a new resolution, and 24 hours pass without this being remedied by
    another proposer and/or sponsors stepping forward, it removed from the
    draft ballot. This does not change the length of the discussion
    period.

    4. If all ballot options except the default option are withdrawn, the
    resolution is canceled and will not be voted on.


    A.3. Calling for a vote

    1. After the discussion period has ended, the Project Secretary will
    publish the ballot and call for a vote. The Project Secretary may do
    this immediately following the end of the discussion period and must do
    so within five days of the end of the discussion period.

    2. The Project Secretary determines the order of ballot options. At their
    discretion they may reword the single-line summaries for clarity.

    3. Minor changes to ballot options under point A.1.5 may not be made after
    or within 24 hours of the end of the discussion period unless the
    Project Secretary agrees the change does not alter the meaning of the
    ballot option and (if it would do so) warrants delaying the vote. The
    Project Secretary will allow 24 hours for objections after any such
    change before issuing the call for a vote.

    4. No new ballot options may be proposed, no ballot options may be
    amended, and no proposers or sponsors may withdraw within 24 hours of
    the end of the discussion period unless this action successfully
    extends the discussion period under point A.1.4 by at least 24
    additional hours.

    5. Actions to preserve the existing ballot may be taken within 24 hours of
    the end of the discussion period, namely a sponsor objecting to an
    amendment under point A.1.3, a Developer objecting to a minor change
    under point A.1.5, stepping forward as the proposer for an existing
    ballot option whose original proposer has withdrawn it under point
    A.2.1, or sponsoring an existing ballot option that has fewer than the
    required number of sponsors because of the withdrawal of a sponsor
    under point A.2.2.

    6. The Project Secretary may make an exception to point A.3.4 and accept
    changes to the ballot after they are no longer allowed, provided that
    this is done at least 24 hours prior to the issuance of a call for a
    vote. All other requirements for making a change to the ballot must
    still be met. This is expected to be rare and should only be done if
    the Project Secretary believes it would be harmful to the best
    interests of the project for the change to not be made.


    A.4. Voting procedure

    1. Options which do not have an explicit supermajority requirement have a
    1:1 majority requirement. The default option does not have any
    supermajority requirements.

    2. The votes are counted according to the rules in A.6.

    3. In cases of doubt the Project Secretary shall decide on matters of
    procedure.


    A.5 is deleted. A.6 is left unchanged. (In the final, formal GR, A.6
    will be renumbered to A.5 with corresponding changes throughout the rest
    of the constitution.)


    When the vote counting mechanism of the Standard Resolution Procedure is
    to be used, the text which refers to it must specify who has a casting
    vote, the quorum, the default option, and any supermajority requirement.
    The default option must not have any supermajority requirements.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Timo =?utf-8?Q?R=C3=B6hling?=@21:1/5 to All on Wed Oct 6 13:00:01 2021
    Hi Russ,

    * Russ Allbery <rra@debian.org> [2021-10-05 21:16]:
    I'm somewhat surprised that there has been no discussion of the timing of
    the GR discussion period, which I expected to be more controversial. The >scheme I'm proposing is relatively complex but allows the discussion
    period to vary from 1 week to 4 weeks based on how much ballot option >activity there is and based on DPL actions. If anyone is unhappy with
    that (if, for example, you think it's too complex or 4 weeks is too short
    or too long), now would be a good time to bring that up so that we can >discuss it.
    Thank you very much for the reminder, and allow me to add my two
    cents:

    The Debian Constitution, like most good constitutions, has this nice
    power hierarchy: at the lower end of the spectrum, a single
    maintainer can act quickly as they see fit, but with limited scope
    and subject to the Constitution and the Policy. (The DPL is not
    unlike a maintainer for the debian-project package in this regard).
    At the upper end, the assembly of all developers has basically
    unlimited powers via GR, but requires exensive deliberations and a
    certain amount of time to decide. The Tech-CTTE is somewhere in the
    middle.

    In a sense, the GR is the Ultimate Weapon for large-scale decisions
    beyond the scope of a single maintainer, a group of maintainers, or
    any other constitutional entity. As such, I regard a certain
    cumbersomeness as a feature, not a bug. I believe it is more
    important to have a well-understood, very predictable process that
    ensures all voices are heard, even if it sacrifices flexibility. We
    already have the DPL and other delegated teams to deal with more
    urgent issues.

    I'd prefer a fixed N week discussion period for some reasonable N
    over any scheme that depends on DD oder DPL actions and may easily
    become subject to rule gaming. At the most, I would add a provision
    to extend the discussion period under certain circumstances if N is
    relatively small. This way, any DD can anticipate the voting period
    well in advance and adjust their personal schedule accordingly to
    make sure they can vote if the issue is important to them.

    And if we identify any topic that requires more urgent decisions on
    a regular basis, I think the GR should not become a micro management
    tool but delegate the necessary power the DPL or some other entity.


    Cheers
    Timo


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

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

    iQGzBAABCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmFdgBoACgkQ+C8H+466 LVlLNAv/RwYJUuit20PYowjn1TMlWuoJ8F/5FnteIjdIAbRDbGiNepcL4or4ACIQ edToDa3+qvSPNkLnfYc2g3qXwEoagkR9JiqxQhE5qq/68jKmatsEpHwjt7wfkLP7 NNhxrroYqyQvaO+1wcy54BuvJkdSFYZRgF9rdLak9CtqhOEr86+7Sdepxf7GbGPA ZWzaIfzsFYfBCf023LThUL4MqfN/37fKcp90P5MmT5fZmQot/MdQv+nmHUABR0aR CYF04FXLGs2our7y0Vz2z24XzcneC3arw55w13gwzvcVijqkDfoaL7xmuHHbKWXo 6wK4WMuTTqEfqZj7FKvYJIFKYZ/GbFibHZZvg5NCDJ1
  • From Russ Allbery@21:1/5 to roehling@debian.org on Sun Oct 10 21:10:02 2021
    Timo Röhling <roehling@debian.org> writes:

    In a sense, the GR is the Ultimate Weapon for large-scale decisions
    beyond the scope of a single maintainer, a group of maintainers, or any
    other constitutional entity. As such, I regard a certain cumbersomeness
    as a feature, not a bug. I believe it is more important to have a well-understood, very predictable process that ensures all voices are
    heard, even if it sacrifices flexibility. We already have the DPL and
    other delegated teams to deal with more urgent issues.

    I'd prefer a fixed N week discussion period for some reasonable N over
    any scheme that depends on DD oder DPL actions and may easily become
    subject to rule gaming. At the most, I would add a provision to extend
    the discussion period under certain circumstances if N is relatively
    small. This way, any DD can anticipate the voting period well in advance
    and adjust their personal schedule accordingly to make sure they can
    vote if the issue is important to them.

    This is an excellent statement of the argument that I personally lean
    towards. I know other folks feel more strongly than I do about giving the
    DPL, or at least the project, some flexibility to deal with more urgent
    issues or to let things take a bit longer, so I left this part in. But I
    have to admit that if I were writing the constitution purely for myself, I would set the discussion period at a fixed three weeks and remove all the complexity for varying it.

    Currently, the DPL can vary the minimum discussion period and the voting
    period by up to one week each, which puts the time required to make a
    decision by GR at an absolute lower bound of two weeks right now. That's already fairly long for anything urgent.

    I don't recall how often the DPL has varied the voting period. My
    possibly erroneous recollection is that this has rarely happened, which increases the minimum time period to three weeks in practice. This is now quite long for anything that's actually urgent.

    Having closely followed a bunch of GRs now, my personal impression is that almost all of the substantitive discussion happens in the first week.
    Some discussion continues into the second week, and for controversial GRs
    a few more options are drafted then. With the systemd GR, the final
    option that made the ballot was proposed just shy of the three week mark, admittedly forced by the vote timing. (For whatever it's worth, that last option was also the only option to not beat further discussion, but there
    was another option proposed a day earlier that did much better.)

    Three weeks therefore seems like a good time period to pick. It felt like
    it was long enough, at least to me, for one of the most complex and controversial GRs to get a ballot that was reasonably comprehensive, and
    it was also the point at which a lot of the project was sick of the
    discussion and had largely tuned it out, which will result in reducing
    quality of discussion for anything proposed after that point. There's
    always going to be an argument for taking a bit longer, but I think it's
    worth taking into account people's attention span and recognizing that
    we're never going to get a perfect GR.

    I'm not sure that it makes much difference whether we decide things in
    five weeks or four weeks, but the first place I'd look to shorten the
    process further would be to fix the voting period at one week instead of leaving it to the DPL to vary, since two weeks always feels like a very
    long voting period. I believe we do get a substantial number of votes in
    the second week, though, so perhaps that's not a good idea. (Two weeks
    does provide some generous flexibility around people's vacations.)

    All that being said, I know other folks have strong opinions about having
    some flexibility and about three weeks being too short, so I was hoping
    they would weigh in here.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Raphael Hertzog@21:1/5 to Russ Allbery on Fri Oct 15 10:00:02 2021
    Hi,

    thank you Russ for driving this discussion forward. I'm pretty happy
    with your proposal.

    On Tue, 05 Oct 2021, Russ Allbery wrote:
    I'm somewhat surprised that there has been no discussion of the timing of
    the GR discussion period, which I expected to be more controversial. The scheme I'm proposing is relatively complex but allows the discussion
    period to vary from 1 week to 4 weeks based on how much ballot option activity there is and based on DPL actions. If anyone is unhappy with
    that (if, for example, you think it's too complex or 4 weeks is too short
    or too long), now would be a good time to bring that up so that we can discuss it.

    On the topic of the length of the discussion period, your proposal tries
    to keep the current spirit while adding some safeguards. I think it's
    good.

    When I try to think of possible simplifications with a fixed period
    of discussion, I end up wanting special cases...

    For example, I find a fixed 3 week period very long, but if we opt for
    that maybe we can authorize an early call for vote (by one of the proposer
    or by the DPL) if no changes to the ballot options happened in the last 5
    days. That way if a discussion dies after one week, we can still shorten
    it to 2 weeks. In practice, it's realy close to your proposed system with
    min and max so in the end I concluded that it's not worth exploring that...

    Thus the only simplification that is acceptable to me is possibly to get
    rid of the DPL power to vary the discussion period. But then the existence
    of min and max period avoids most of the problem that could be introduced
    by this power.

    I think we should aim at shortening the voting period too, but likely not
    by much. I would make the voting period last at least 9 days (and no more
    than 14) with a requirement to include two week-ends. Then the secretary
    should have some leeway in fixing the start and the end based on his own availability.

    Here is my current draft:

    I saw some interesting discussion about the need to remove the 2:1
    majority requirement to overrule the TC in case the decision has been made
    with the chair casting vote, but I don't see any language for this.

    Is there any reason for this?

    Cheers,
    --
    ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
    ⣾⠁⢠⠒⠀⣿⡁
    ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
    ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bill Allombert@21:1/5 to Russ Allbery on Fri Oct 15 20:00:02 2021
    On Sun, Oct 10, 2021 at 12:01:35PM -0700, Russ Allbery wrote:
    Having closely followed a bunch of GRs now, my personal impression is that almost all of the substantitive discussion happens in the first week.
    Some discussion continues into the second week, and for controversial GRs
    a few more options are drafted then. With the systemd GR, the final
    option that made the ballot was proposed just shy of the three week mark, admittedly forced by the vote timing. (For whatever it's worth, that last option was also the only option to not beat further discussion, but there
    was another option proposed a day earlier that did much better.)

    I do believe reducing the discussion period gives too much head start to
    the proposing parties, by contrast to others developers that may not
    have allocate time to participate in such discussion at this point of
    the time. This is a matter of fairness.

    I also believe that the systemd GR was too atypical to serve as an example.

    Cheers,
    --
    Bill. <ballombe@debian.org>

    Imagine a large red swirl here.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Raphael Hertzog on Fri Oct 15 20:00:02 2021
    Raphael Hertzog <hertzog@debian.org> writes:

    I think we should aim at shortening the voting period too, but likely
    not by much. I would make the voting period last at least 9 days (and no
    more than 14) with a requirement to include two week-ends. Then the
    secretary should have some leeway in fixing the start and the end based
    on his own availability.

    Do you think this is something that we should tackle as part of this GR or
    as a separate change? It feels somewhat orthogonal to me.

    Here is my current draft:

    I saw some interesting discussion about the need to remove the 2:1
    majority requirement to overrule the TC in case the decision has been
    made with the chair casting vote, but I don't see any language for this.

    Is there any reason for this?

    I floated the idea but I don't believe anyone has supported the proposal
    that I made, and I don't think there's more than one person expressing
    support for any other specific proposal. I was letting the discussion
    continue (I owe another response in that thread), but I don't want to add anything substantive to the GR draft unless there's a fairly clear
    consensus in favor of it. So if folks would like to see this change as
    well, please speak up!

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bill Allombert@21:1/5 to Russ Allbery on Sat Oct 16 15:40:03 2021
    On Fri, Oct 15, 2021 at 10:56:44AM -0700, Russ Allbery wrote:
    Bill Allombert <ballombe@debian.org> writes:

    I do believe reducing the discussion period gives too much head start to the proposing parties, by contrast to others developers that may not
    have allocate time to participate in such discussion at this point of
    the time. This is a matter of fairness.

    I completely agree that there is a concern of fairness here (and think it
    is exacerbated by the current rules for how to call for a vote).

    What do you think of the approach in my current proposal? The intent
    there is to make the minimum period long enough (and also provide a way to extend it by at least a week by proposing a placeholder ballot option if
    need be) to try to remedy this.

    Generally speaking, while I am in favor of making the decision-making
    process fairer and less subject to interpretation, I am not in favor of
    making it faster.
    Three weeks is already a very short time in Debian term.
    A fast decision making process could quickly lead to the implosion of
    Debian.
    It takes time to understand what will be the actual effect of a proposed resolution.

    It happened that a number of developers did not understand what the
    consequence of the vote was until after it was concluded. This is to be avoided.

    The majority of DD do not vote for GR, and objectively the proportion of stakeholders with voting right has been decreasing. This is to take into account.

    Cheers,
    --
    Bill. <ballombe@debian.org>

    Imagine a large red swirl here.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Bill Allombert on Sat Oct 16 17:50:02 2021
    Bill Allombert <ballombe@debian.org> writes:

    Generally speaking, while I am in favor of making the decision-making
    process fairer and less subject to interpretation, I am not in favor of making it faster. Three weeks is already a very short time in Debian
    term. A fast decision making process could quickly lead to the
    implosion of Debian. It takes time to understand what will be the
    actual effect of a proposed resolution.

    Thank you! That helps me understand your position.

    I'm sorry to focus so much on my specific proposal, but since it's what
    I'm trying to put into a shape such that everyone is comfortable with it,
    I kind of have to. Do you believe my proposal makes decision-making
    faster, and thus is objectionable under that criteria?

    I believe that it doesn't, but perhaps I'm missing something.

    The current rule is two weeks plus or minus a week via the DPL, after
    which any developer -- the text doesn't say that but that's the result of
    the current wording -- can call for a vote provided that the original GR proposer doesn't accept amendments. My proposal also says two weeks plus
    or minus a week via the DPL, but if there are additional ballot options
    the time automatically extends to three weeks. I therefore think it
    roughly maintains the current timing, and to the extent that it changes
    it, it generally lengthens the discussion period by up to a week, although
    it's possible to get a longer discussion period out of the current system
    if the original GR proposer accepts a lot of amendments.

    In other words, is the current proposal something that you would support provided that the discussion period isn't made any shorter?

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bill Allombert@21:1/5 to Raphael Hertzog on Sat Oct 16 22:10:01 2021
    On Fri, Oct 15, 2021 at 09:58:23AM +0200, Raphael Hertzog wrote:
    I think we should aim at shortening the voting period too, but likely not
    by much. I would make the voting period last at least 9 days (and no more than 14) with a requirement to include two week-ends. Then the secretary should have some leeway in fixing the start and the end based on his own availability.

    Given the low voter turnout in most GRs, we should rather extend the
    voting period to give more chance to DDs to vote.
    Here also, DDs that have participated to the debian-vote discussion will
    be able to vote with full information as soon as the vote open.

    For the others, this require allocating time to dig through the vote
    options, and what are their actual effects, and decide on a ranking.
    Not all developers can use their week-end for that task.

    But it is precisely the input of the DDs that did not participate in the discussion which is the most important for the project to get and that
    the vote process is supposed to gather.

    Cheers,
    --
    Bill. <ballombe@debian.org>

    Imagine a large red swirl here.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Raphael Hertzog@21:1/5 to Bill Allombert on Mon Oct 18 10:50:02 2021
    Hi,

    On Sat, 16 Oct 2021, Bill Allombert wrote:
    Given the low voter turnout in most GRs, we should rather extend the
    voting period to give more chance to DDs to vote.

    If lengthening the period would result in that, I would happily accept
    it but I think this is not really the case (or only marginally so)
    because as you point out the issue is the cost of having to dig through
    the various options, possibly reading up part of the discussion, reading
    up opinions of respected DD, etc.

    I assume that when DD don't vote, it's either because they don't care or because they don't want to take the time to make up their mind to fill an informed ballot. If the vote is about something you care about, you will
    find the required time.

    For the others, this require allocating time to dig through the vote
    options, and what are their actual effects, and decide on a ranking.
    Not all developers can use their week-end for that task.

    Well, the vote is open every day... I wanted to keep at least two
    week-ends because that's the period where most casual Debian contributors
    are likely to have some free time to read up and fill a ballot.

    Cheers,
    --
    ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
    ⣾⠁⢠⠒⠀⣿⡁
    ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
    ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS

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