Re: Opposing strict time limits

[Richard Laager]

In general, I understand the reasoning for having an option for longer 
discussions. However, I see risks too.


On 10/22/21 12:42 PM, Wouter Verhelst wrote:

a vote to recall the project leader.


This is an interesting corner case. I don't think it needs a special 
case under the current situation or Russ's proposal, as the time is not 
unbounded. But we should be careful not to make the time unbounded 
except by DPL action ("only provide it to the DPL") as that would 
effectively insulate the DPL from recall.


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Re: Opposing strict time limits

[Felix Lechner]

Hi,

On Fri, Oct 22, 2021 at 11:23 AM Russ Allbery  wrote:
>
> To fully achieve what Wouter is calling for would therefore *also* require
> a constitutional change.

As a proponent of a living process, I would welcome such an
alternative on the ballot.

Russ's motivation strikes me as extremely noble: With rules, people
feel treated fairly. At the same time, better rules do not make better
decisions. For Debian—a free-spirited volunteer project—I find
Wouter's vision of a healthy and flexible democratic process more
compelling. Why not put the people first?

Being new, I wrote with some hesitation. Thank you for reading!

Kind regards
Felix Lechner

Re: Opposing strict time limits

[Pierre-Elliott Bécue]

Wouter Verhelst  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 

Re: Opposing strict time limits

[Russ Allbery]

Thank you for raising this, Wouter!

I'm not going to reply directly to the substance of this argument right
now because Wouter already knows my opinion and I think having the rest of
the project weigh in would be much more useful.  Part of the goal here is
to come up with a system that's more predictable and fair for everyone, so
if having prolonged discussion periods is important to others, I'd like us
to have that discussion so that we can explore the nuances.

I did want to make one technical point, though:

Wouter Verhelst  writes:

> I think introducing a fixed time limit on a GR is a bad idea, for
> various reasons.

It's fair to say that my proposal introduces a fixed time limit in the
sense that the current constitution *in theory* allows the discussion
period to be unbounded.

However, I think it's important to note that *in practice* the current
constitution also has a time limit on a GR, which can only be increased
(beyond the week allowed to the DPL) by either the original proposer of
the GR (not the proposer of any other ballot option) by regularly
accepting new amendments, or by the cooperative choice of every Debian
Developer to not call for a vote.  In practice, without the active
cooperation of the proposer of the GR, the current constitution imposes a
fixed time limit of two weeks on the discussion period (or three weeks
with a DPL extension).  It just doesn't automatically enforce this and
instead leaves it to any Debian Developer to enforce it, which means in
practice it sometimes runs a bit longer but generally not that much
longer.

Under the current constitution, once two weeks have passed, unless the
original GR proposer accepts an amendment to reset the clock, any Debian
Developer can force a vote by seconding the original proposal and then
calling for a vote.

This means that the discussion period could be unbounded in cordial cases
where no one is in any hurry and no one wants to force the issue, but as
soon as the proposal becomes controversial in some way, it's highly likely
that someone will impose the time limit and force a vote.  (Whether you
consider that a feature or a bug of course depends on your opinion about
extended discussion periods.)

To fully achieve what Wouter is calling for would therefore *also* require
a constitutional change.  It's not a preservation of the existing status
quo.  I know Wouter knows that, but I wanted to make sure it was explicit
for everyone else.

-- 
Russ Allbery (r...@debian.org)  

Opposing strict time limits

[Wouter Verhelst]

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