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

Re: Opposing strict time limits

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

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



Attachment: signature.asc
Description: PGP signature

Reply to: