Sam Hartman <hartm...@debian.org> writes: >>>>>> "Wouter" == Wouter Verhelst <wou...@debian.org> writes:
> Wouter> Can you shed some light on your opinion here? I've tried to > Wouter> build an option that I hope can achieve some form of > Wouter> consensus, and I would like to know whether I have succeeded > Wouter> in doing so. I don't think I'll change much if not, but it > Wouter> would be useful information nonetheless. > Russ's option has a maximum time for discussions. > Yours does not. Wouter's system exhausts K+1 votes for extending the discussion period each time it is extended, so technically it does impose a maximum time assuming that we don't add new developers during the discussion period at a rate equal to or greater than 6 developers every three days (which seems unlikely). The question is how long that maximum time would be in practice. This was one of the things that I was curious about and hadn't taken the time to do some calculations. This message reminded me I wanted to do that, so I took a moment to do so. The most concerning scenario from my perspective is if a group that believes they would lose a GR attempts to postpone it to avoid losing (perhaps in the hope that by stalling conditions will change). If a majority of the project wants to stall a GR, that's less concerning. I think that would still be quite bad for the project if it happened, but I think it's less likely to happen and the GR would eventually fail anyway, so that stalling isn't postponing an action the project would then take. So, let's analyze that case and see how far back a vote could be pushed. Between the last two GRs and the last two DPL elections, the vote with the largest number of unique voters was 455. Assume for the sake of argument that we're trying to decide something on which the project is split 60/40. I'm quite certain that not everyone opposed to a GR would be willing to constantly delay it; suppose that half those opposed are so willing (I think this is wildly high). That says 20% of the voters would be willing to support a delay, or 91 people. Assume K is 5, so 6 people are required for each three day delay. The vote could then be delayed 15 times, or 45 days, so about six and a half weeks on top of an initial three week discussion period, for a total discussion period of close to ten weeks. (This is not precisely accurate since the DPL can delay the vote one time without requiring seconds, and the TC can delay the vote one time acting as the TC separate from acting as individuals, but I think it's safe to ignore those cases for the purposes of this back-of-the-envelope analysis.) This analysis is very sensitive to the percentage of people in the minority who would be willing to delay the vote. I think a more likely number (probably still too high) would be at most 10% of the voters (a quarter of those in the minority), which would allow 7 delays, or 21 days (3 weeks), for a maximum discussion period of six weeks. Wouter, I think your proposal would be more attractive to those of us who are concerned with not allowing a GR to be unnecessarily prolonged if you would consider closing off that tail risk of a truly excessive delay. If, for example, you capped the maximum discussion period at six weeks, which per the above analysis is probably as long as it realistically would be delayed anyway, it would provide some psychological reassurance that the process can't drag on forever. I personally would still prefer a maximum discussion period of substantially less than six weeks and am highly dubious of the benefits (and quite worried about the harms) of a six week discussion period. I also think this system makes the voting process more open to procedural manipulation than my proposal (although this is more a gut feeling than anything concrete, and it's arguable), and essentially forecloses the project's ability to take any timely action without essentially unanimous consensus, so I would still favor my proposal. But it would make me more comfortable with voting this proposal above further discussion. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
