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}
signature.asc
Description: PGP signature
