Re: Opposing strict time limits
Sam Hartman <hartmans@debian.org> writes:
>>>>>> "Wouter" == Wouter Verhelst <wouter@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: