[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Opposing strict time limits



>>>>> "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.

Attachment: signature.asc
Description: PGP signature


Reply to: