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 month. Of course, if the future shows otherwise, we could still rollback this particular aspect. Cheers! -- PEB
Attachment:
signature.asc
Description: PGP signature