Re: Opposing strict time limits

[Russ Allbery]

Felix Lechner  writes:
> On Mon, Nov 8, 2021 at 9:49 AM Russ Allbery  wrote:

>> If your point is, instead, that Wouter's general system is undesirable
>> yes, I largely agree

> Without reflecting on either proposal, I merely cautioned that
> constitutional amendments should be based on sound premises.

...okay?  I truly don't understand why you felt moved to caution me about
that, but sure, I agree with that principle.  I believe my constitutional
amendment is based on sound premises; if I didn't, I wouldn't have made
it.  :)

> As to the point between you and Wouter, is there perhaps a simpler
> measure when a discussion is over—such as one week without a proposal
> that attracted at least three novel supporters (in total)?

I think this is functionally equivalent to Wouter's proposal except even
weaker (you've replaced 6 with 3), so I would prefer Wouter's proposal to
that one.

I suppose the counter-balance is that you say "proposal," by which I
assume you mean ballot option, so each group wanting to delay further has
to produce a concrete proposal, but that makes me less comfortable with it
because it creates an incentive to essentially "spam" the ballot with
proposals in order to achieve the desired goal of extending the discussion
period.  Wouter's proposal seems better since it allows people to ask
directly for what they want (a delay) without having to work around the
spirit of the rules to achieve it.

This is also an advantage of Wouter's proposal over mine: my system also
creates an incentive to add a ballot option only to extend the discussion
period.  That's also not ideal; I just couldn't see a way of avoiding it
without adding what felt like too much complexity.  In my system, that
extension is limited to (normally) an additional week (the intent is to
give people some time to absorb the implications of a new proposal), so I
think the incentive for new ballot options as a procedural maneuver rather
than a true option is lesser and probably won't be an issue in practice.
I also wanted to allow addition of a placeholder option that could be
fleshed out later, and this seemed the simplest way to do that.

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

Re: Opposing strict time limits

[Felix Lechner]

Hi

On Mon, Nov 8, 2021 at 9:49 AM Russ Allbery  wrote:
>
> If your point is, instead, that Wouter's general system is undesirable
> yes, I largely agree

Without reflecting on either proposal, I merely cautioned that
constitutional amendments should be based on sound premises.

As to the point between you and Wouter, is there perhaps a simpler
measure when a discussion is over—such as one week without a proposal
that attracted at least three novel supporters (in total)?

Kind regards
Felix Lechner

Re: Opposing strict time limits

[Russ Allbery]

Felix Lechner  writes:

> The question did not have an answer. [1] To avoid pain, the project
> prefers shorter discussions on controversial topics. It is the opposite
> of what you wrote.

I think the detail that you may be missing is that under Wouter's system
for extending the discussion period, it doesn't matter what the project as
a whole wants.  The extension is not decided by vote; opposition is not
counted.  Rather, any six (K+1) Developers can extend the discussion
period, regardless of anyone else's opinion of whether that's a good idea.

What I wrote, which kicked off this subthread, was:

This preserves the same minimum discussion period (1 week), but makes
it very easy to extend it to two weeks and moderately easy to extend
it to three weeks.  This will probably happen for all but the most
urgent and uncontroversial GRs.

I believe it is correct to say that, should we adopt a system such as that
modification of Wouter's proposal, one will be able to find at least 6
Developers to extend the discussion period two two weeks for all but the
most urgent and uncontroversial GRs, and that it is highly likely that one
will be able to find 12 Developers to extend it to three weeks.  It's a
very low bar of support: about 3% of the voting membership to extend to
three weeks.  As we've seen in the discussion, some folks believe the
discussion period should be longer for (nearly) all votes as a matter of
principle, and would presumably routinely support such an extension.

That proposed system may still be a bad idea, to be clear.  I think it
provides a rather dramatic simplification of the discussion period length
over either my proposal or Wouter's original proposal (and over the
existing constitution), which has a lot of appeal at least to me.  (All
things being equal, I think simpler systems are better than more complex
systems.)  But it does place a burden on people to propose an extension
for any GR whose discussion period should be longer than a week, which may
not be desirable.

If your point is, instead, that Wouter's general system is undesirable
because it allows the discussion period to be extended longer than the
project as a whole may wish discussion periods extended, since the project
as a whole may prefer shorter discussions on controversial topics, well,
yes, I largely agree, which the root of why I prefer my original proposal
over Wouter's.

To add some more detail to that, I think there is a trade-off.  Longer
discussion periods do produce better proposals and a richer variety of
options, plus are simply better from a democratic perspective since they
give people more time to become aware of the proposal and to think about
it in detail.  But I think we can all agree that there is a point of
diminishing returns (although we may disagree about where that point is).

For example, making the discussion period of every GR take a minimum of
one year would probably produce better-crafted final results (I do know of
one organization whose bylaws work this way), but I don't think that's
what we want.  It sacrifices timeliness and it requires anyone who wants
to make a change sign up for an extended effort.

Also, for Debian, the other aspect of the trade-off is that, for
controversial GRs, the pattern has been that the discussion gets more
heated and divisive as it goes on.  People start repeating themselves,
they get angrier that no one is changing their mind, the messages get more
personal, and I felt like I could watch people's views become more
entrenched and less generous to those with whom they disagreed.  So I
believe there is also some harm that is done by extended discussion
periods, and we have to balance that against the benefit achieved by
having better proposals and more time for people to absorb the proposal.

My proposal (not the modification of Wouter's but the one that I'm
bringing to GR) chooses to strike that balance by putting it at roughly
the same place the balance lies today with the existing system (the
current minimum is two weeks and for recent controversial GRs we've gone
three weeks), but making that timing more predictable so that people have
clear deadlines to work towards and the timing of the vote isn't as
susceptible to strategic maneuvering.  It's not a very ambitious change;
it probably shortens the formal discussion period a bit on average, but
not a lot.

My theory is that we're probably not too far off from the right balancing
point in that trade-off right now, and the DPL retains the ability to vary
things by a week in either direction if, for a given GR, they believe that
the balance isn't quite right.  My theory is also that three weeks is a
sufficiently long time to absorb a proposal and come up with a
counter-proposal if everyone knows there is a deadline, so that the
original GR proposer doesn't have an unfair advantage.

One certainly may disagree with those theories!  I believe Wouter does,
and hence his alternate proposal, which 

Re: Opposing strict time limits

[Felix Lechner]

Hi,

On Mon, Nov 8, 2021 at 7:43 AM Russ Allbery  wrote:
>
> Maybe you could
> try rephrasing in the hope that I may understand a different version of
> the question better?

The question did not have an answer. [1] To avoid pain, the project
prefers shorter discussions on controversial topics. It is the
opposite of what you wrote.

Secret votes will reduce fear, but for a wholesome remedy contributors
have to forgo provocation and punishment and instead seek compromise
and common ground. Both will lead to a lasting peace.

Kind regards
Felix Lechner

[1] https://en.wikipedia.org/wiki/Rhetorical_question

Re: Opposing strict time limits

[Russ Allbery]

Felix Lechner  writes:
> On Sun, Nov 7, 2021 at 5:13 PM Russ Allbery  wrote:

>> I don't understand the question.  That system does not currently exist,
>> and therefore this could not have happened

> Without wanting to take up too much bandwidth, I believe that deductive
> logic misses key insights. [1]

> More broadly, you are not the only one who thinks I have strange
> feathers. I mean, what is this guy talking about? He has so much to
> learn! Perhaps this short video [2] can shed some light on how two
> parties might examine the same subject from two sides. In some form, it
> will solve Debian's social issues.

My response was not intended as a critique of your way of thinking.  I
really did mean my response literally: I don't understand your question.
That makes it hard for me to respond to it, or to take into account any
key insights that it contains.

I tried to explain why I didn't understand the question.  Maybe you could
try rephrasing in the hope that I may understand a different version of
the question better?

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

Re: Opposing strict time limits

[Felix Lechner]

Hi,

On Sun, Nov 7, 2021 at 5:13 PM Russ Allbery  wrote:
>
> I don't understand the question.
> That system does not currently exist, and therefore this could
> not have happened

Without wanting to take up too much bandwidth, I believe that
deductive logic misses key insights. [1]

More broadly, you are not the only one who thinks I have strange
feathers. I mean, what is this guy talking about? He has so much to
learn! Perhaps this short video [2] can shed some light on how two
parties might examine the same subject from two sides. In some form,
it will solve Debian's social issues.

Kind regards
Felix Lechner

[1] https://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems
[2] https://www.youtube.com/watch?v=LltoUg_WL2k

Re: Opposing strict time limits

[Russ Allbery]

Felix Lechner  writes:
> On Sun, Nov 7, 2021 at 3:53 PM Russ Allbery  wrote:

>> makes it very easy to extend it   This will probably happen for all
>> but the most urgent and uncontroversial GRs.

> Didn't we just see the opposite?

I don't understand the question.  This statement is in the context of
Wouter's system for extending the discussion period via a proposal and
sponsors.  That system does not currently exist, and therefore this could
not have happened or not happened in any previous GR.

> In the most recent referendum, the decisive argument for shortening was
> the existence of hardened fronts rather than a lack of controversy. Sam
> suspected that people had made up their minds. [1]

In the most recent referendum, the DPL shortened the discussion period,
which the current constitution gives the DPL the power to do.  The
proposal to which you're responding is to drop that provision entirely in
favor of Wouter's system for deciding on extensions of the discussion
period.  That modification of Wouter's system does not have any mechanism
for *shortening* the discussion period (instead, it starts at one week and
can only be lengthened), so no argument for shortening would even be
relevant in that system.

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

Re: Opposing strict time limits

[Felix Lechner]

Hi,

On Sun, Nov 7, 2021 at 3:53 PM Russ Allbery  wrote:
>
> makes it very easy to extend it 
> This will probably happen for all but the most urgent and
> uncontroversial GRs.

Didn't we just see the opposite? In the most recent referendum, the
decisive argument for shortening was the existence of hardened fronts
rather than a lack of controversy. Sam suspected that people had made
up their minds. [1]

The DPL later cited urgency, but did so without an explanation and in
an apparent attempt to end the fighting quickly. [2] The vote was
urgent only because it threatened to tear the community apart.

The outcome was close, too—and anything but uncontroversial.

Kind regards
Felix Lechner

[1] https://lists.debian.org/debian-vote/2021/03/msg00106.html
[2] https://lists.debian.org/debian-vote/2021/03/msg00115.html

Re: Opposing strict time limits

[Russ Allbery]

It looks like discussion of this option has died down, so now is probably
a good time for me to express my personal opinion for why I prefer my
option, now that it hopefully won't skew any of the discussion from
others.

I understand your analysis for why you don't want a fixed time limit on
discussion, and I think we're just coming to this with different
assumptions and preferences.  What I see in your analysis is a focus on
getting the best ballot options possible and a belief that more discussion
leads to better options.  I'm dubious this is true (I think this is a
matter of opinion on which we're unlikely to convince each other), and
also don't feel like my personal view is represented in your analysis:
that arriving at a decision in a timely fashion is usually more important
than getting the absolute best options on the ballot, that longer
discussion periods are often destructive to project unity rather than
leading to better decisions, and that long discussion periods increase the
burden of anyone who wants to address an issue via GR and therefore lead
to leaving problems unresolved because a GR is too much work.

A lot of the problems I see are deeply embedded and my proposal won't
resolve them all, but I think capping the maximum discussion period is far
more helpful than harmful in arriving at a good decision.  I think you may
be underestimating the benefits of a timely process, and overestimating
the benefits of developing another ballot option.  I also think that
setting a time limit on how long a GR proposer is expected to participate
in and guide a process will be helpful for allowing more people to be
willing to commit to that work.

Obviously, I could be wrong about these things!  But this is where I'm
coming from personally.

As mentioned earlier, I don't think one has to agree with all of my
beliefs about this process to support my proposal.  I think it's a
compromise (I'd prefer a shorter starting maximum discussion period
myself), and preserves a lot of the behavior of the existing system rather
than making a more significant change.  As mentioned earlier, I don't
think my proposal decreases the maximum length of the discussion process
in most circumstances; it just makes predictable and concrete what's
already implicit in our current system.

In a similar spirit, although your proposal isn't my preference and I'm
quite worried about the deleterious effects of allowing repeated
extensions of the discussion period, I think it's a very interesting
proposal.  The approach of exhausting votes for extending the discussion
period hadn't occurred to me, and I think it's a quite elegant way of
avoiding going all the way to a voting system for discussion period
extensions.  I'm inclined to support it above further discussion (although
I prefer my proposal).

One thing I did notice when re-reading it: the interaction between the DPL
varying the length of the discussion and the extensions seems complicated
and not entirely clear to me, and I'm also not sure I like timing the
extensions from the point at which they're sponsored as opposed to
relative to the current discussion period.  I wonder if you could make the
system even simpler, producing a scheme that has some admirable simplicity
advantages over my proposal.  Something like this:

1. The discussion period starts when a draft resolution is proposed and
   sponsored.  The length of the discussion period starts at 1 week.

2. An extension to the discusison period may be proposed and sponsored
   according to the requirements for a new resolution.  As soon as a
   discussion period extension reaches the required number of sponsors, it
   takes effect and cannot be withdrawn.

3. The first two times the discussion period is extended add an additional
   week to the length of the discussion period.  Subsequent extensions add
   an additional 72 hours.

4. The proposer and sponsors of an extension to the discussion period may
   not propose or sponsor any additional extensions to the discussion
   period for the same General Resolution.

5. The discussion period may not be extended beyond six weeks.

and then drop not only the language about extending the discussion period
when the ballot changes but also all the language for the DPL varying the
length of the discussion period, and use this system as the only mechanism
for changing the length of the discussion period.

This preserves the same minimum discussion period (1 week), but makes it
very easy to extend it to two weeks and moderately easy to extend it to
three weeks.  This will probably happen for all but the most urgent and
uncontroversial GRs.  It also entirely avoids the problem (still present
in my proposal) of the DPL having to make an often-politicized decision
about varying the discussion period.

(I also agree with Sam's comment that a note about when an extension of
the discussion period is appropriate would probably be useful, although I
did not attempt to incorporate that into 

Re: Opposing strict time limits

[Sam Hartman]

> "Russ" == Russ Allbery  writes:
Russ> This analysis is very sensitive to the percentage of people in
Russ> the minority who would be willing to delay the vote.  I think
Russ> a more likely number (probably still too high) would be at
Russ> most 10% of the voters (a quarter of those in the minority),
Russ> which would allow 7 delays, or 21 days (3 weeks), for a
Russ> maximum discussion period of six weeks.

I did less math, but my intuition was the same.
My intuition was that you could probably get six weeks of delay for a GR
that some minority really didn't like.
Beyond that, I guess the political back pressure would be strong enough
to git rid of the delay mechanism after the triggering GR was dealt
with.

I don't think adding a maximum matters to me much because I think that
the practical maximum is somewhere between 6-9 weeks.

I definitely prefer Russ's proposal.

One concrete change I'd request would be language added  that said what
the delays should be used for.
Something like "Delays should only be used to provide time to develop
additional ballot options and not to delay the vote on a GR that those
seeking a delay find objectionable."
Such language, particularly if phrased with should language, has no
normative effect based on how the constitution defines should.

However, I think it might have behavioral effects in terms of setting
community expectations.
For example I could ask someone what ballot option they were working on
if they proposed a delay.
And if it was clear that they were not, our normal mechanisms for
approaching behavior inconsistent with our norms could be applied.


signature.asc
Description: PGP signature

Re: Opposing strict time limits

[Gerardo Ballabio]

Russ Allbery wrote:
> 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.

What about this.
- any developer may request an extension of one week
- the request is granted if L>=K developers second it
- but it is denied if M>=L developers oppose it
- if the DPL seconds or opposes the request, that counts as K votes
(this means that the DPL can get an extension alone if nobody opposes,
but can't force an extension if enough developers oppose)
- the extension must be requested at least 48 hours before the end of
the current discussion period, in order to give opposers enough time
to speak out
- that can be repeated any number of times, or no more than a fixed
number of times, say three

Gerardo

Re: Opposing strict time limits

[Russ Allbery]

Sam Hartman  writes:
>> "Wouter" == Wouter Verhelst  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)  

Re: Opposing strict time limits

[Sam Hartman]

> "Wouter" == Wouter Verhelst  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.

However, I think you've done a good job of coming up with counters for
most of the abuses that we thought of here, and so I think it likely
that your option would be a significant improvemement over the status
quo.

Re: Opposing strict time limits

[Wouter Verhelst]

On Sun, Oct 24, 2021 at 08:41:15PM -0600, Sam Hartman wrote:
> Interesting:-)
> I'd have to think hard about whether to rank that proposal above or
> below FD.
> I prefer Russ's option, but given your goals I agree this sounds like a
> good way to achieve them.

Can you shed some light on your opinion here? I've tried to build an
option that I hope can achieve some form of consensus, and I would like
to know whether I have succeeded in doing so. I don't think I'll change
much if not, but it would be useful information nonetheless.

Thanks in advance,

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Opposing strict time limits

[Wouter Verhelst]

Hi Nikolaus,

On Mon, Oct 25, 2021 at 11:20:13AM +0100, Nikolaus Rath wrote:
> On Oct 22 2021, Wouter Verhelst  wrote:
> > 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),
> 
> How about something like this?
> 
> "My proposing or seconding a ballot option, every proposer/amender
> commits to rank this option above FD and (in case of multiple ballot
> options) higher than at least half of all the options. Should the
> proposer/amender's ballot not confirm reflect this at the time of the
> vote, proposer's/amender's vote will not be counted."

I had considered something along those lines, but decided against it.
Firstly for the same reason that Sam also pointed out: people should be
allowed to change their minds.

Additionally, while I think it is wrong to *draft* an option that you
consider incorrect, I do not consider it wrong to *second* an option
that you consider incorrect. As an example, consider that AJ Towns
seconded GR 2006_005, his own recall vote. I think that was a
reasonable thing to do, and I don't think we should forbid such behavior
by anyone. If you consider that plus the fact that Russ's proposal
allows proposers to withdraw their ballots, then this would incentivize
withdrawing proposals that otherwise still have sufficient support,
which is not necessarily a good idea.

So thanks, but no thanks :)

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Opposing strict time limits

[Holger Levsen]

hi,

i'm just following along, so please excuse my brief comments from the
sidelines...

On Mon, Oct 25, 2021 at 11:15:18AM -0600, Sam Hartman wrote:
> Wouter and I are going to disagree on this, but I actually think that
> the work I did during the latest systemd vote significantly helped move
> the discussion forward.  By trying to listen to various sides and trying
> to present several options I think I managed to frame the process in a
> way that was more constructive.
> 
> I'm sure that process can be refined.  But I'd rather see DPLs do that
> work more rather than less.
> 
> I also don't want to see that work restricted to the DPL.  In many cases
> I'd rather see ballot options drafted by people in the middle rather
> than by strong proponents of a polarized position.

actually I'm not so sure I want the DPL to be regularily involved in such
activities. Undoubtfully these activities are usefull, but I fear they
might be less useful when done by the DPL...

[this is a generic remark, not based on the systemd vote.]

> 1) Remember that we want to move toward secret ballots.

Do *we*, really? I'm not sure I like the idea but at least I recall some
people discussing this. Also I'm pretty sure many people^wDebian members have
not even heard this being discussed.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If you upload your address book to "the cloud", I don't want to be in it.


signature.asc
Description: PGP signature

Re: Opposing strict time limits

[Sam Hartman]

> "Nikolaus" == Nikolaus Rath  writes:

Nikolaus> On Oct 22 2021, Wouter Verhelst  wrote:
>> 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),

Nikolaus> How about something like this?

Nikolaus> "My proposing or seconding a ballot option, every
Nikolaus> proposer/amender commits to rank this option above FD and
Nikolaus> (in case of multiple ballot options) higher than at least
Nikolaus> half of all the options. Should the proposer/amender's
Nikolaus> ballot not confirm reflect this at the time of the vote,
Nikolaus> proposer's/amender's vote will not be counted."

Wouter and I are going to disagree on this, but I actually think that
the work I did during the latest systemd vote significantly helped move
the discussion forward.  By trying to listen to various sides and trying
to present several options I think I managed to frame the process in a
way that was more constructive.

I'm sure that process can be refined.  But I'd rather see DPLs do that
work more rather than less.

I also don't want to see that work restricted to the DPL.  In many cases
I'd rather see ballot options drafted by people in the middle rather
than by strong proponents of a polarized position.


I'll note that it seems very likely that all the options I proposed
would have been preferred to FD.  (We don't quite know for sure because
Proposal C was withdrawn in favor of Proposal F).

The restrictions you propose would make this sort of framing the
discussion and putting together a slate more difficult, and so I think
it's a really bad idea because I think it takes away one of the tools
that shows promise in reducing conflict in Debian.

Even if you agree with wouter's goal, I think there are a couple of
problems:

1) Remember that we want to move toward secret ballots.
I think your proposal is either impossible to implement with secret
ballots, impossible to verify, or exposes enough information that it
would compromise secrecy.  That depends on exactly how the secretary
chose to implement secret ballots and your proposal.

2) Your proposal gets in the way of people changing your mind.  In
effect, you're asking people to lock in their positions.  That
contributes to the sort of polarization and conflict that I'd like to
see us avoid.

--Sam


signature.asc
Description: PGP signature

Re: Opposing strict time limits

[Nikolaus Rath]

On Oct 22 2021, Wouter Verhelst  wrote:
> 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),

How about something like this?

"My proposing or seconding a ballot option, every proposer/amender
commits to rank this option above FD and (in case of multiple ballot
options) higher than at least half of all the options. Should the
proposer/amender's ballot not confirm reflect this at the time of the
vote, proposer's/amender's vote will not be counted."


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Opposing strict time limits

[Wouter Verhelst]

On Sun, Oct 24, 2021 at 03:53:38PM -0500, Richard Laager wrote:
> On 10/24/21 2:01 PM, Wouter Verhelst wrote:
> > 6. The project leader may, at any point in the process, set the
> > discussion period to any length between 1 and 3 weeks, except that
> > they may not do so in a way that causes the discussion period to end
> > within 48 hours of when this change is made, unless that would
> > require them to set a discussion time beyond three weeks.
> 
> What is the purpose/intent of the "unless" here? If the discussion period is
> coming right up on (< 48 hours) 3 weeks, can the DPL truncate it using this?

It was never my intention to allow the DPL to override a time extension.
I see now that that is indeed not forbidden in my proposal; this is an
oversight that I will need to remedy. Thanks for pointing that out.

The wording I use allows the DPL to reduce and then lengthen the
discussion time to any point between one and three weeks.

If the DPL reduced the discussion time to, say, two weeks, and then
through the other process the discussion time is lengthened to 3 weeks
minus a day, then in the time window between 3 weeks minus 48 hours and
when the discussion time is now scheduled to end, the DPL would not be
allowed to lengthen the discussion time again to the maximum of three
weeks. I think that would be suboptimal.

But I realize now that the "causes" in that sentence already covers
that, so I can probably drop that "unless" cause and leave the paragraph
as-is.

> > 10. When a time extension has received the required number of seconds,
> >  the discussion time is extended to end 72 hours from when the
> >  extension was first proposed.
> 
> This wording might need some tweaking for clarity/anti-abuse. Specifically,
> if I ask for and receive an "extension" when there was more than 72 hours
> left already, what happens?

Two things:

- The DPL will not be able to reduce the discussion time to less than
  the 72 hours your extension gives you
- You will not be able to ask or second another extension.

... but nothing beyond that. Specifically, the discussion time will not
be extended beyond the original time, because your extension falls
entirely within the existing discussion period.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Opposing strict time limits

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:
Wouter> However, the problem I see with strict timings that cannot
Wouter> be extended in any possible scenario is that we may end up
Wouter> with a situation where one option cannot be fleshed out
Wouter> entirely due to lack of time. I think it's unrealistic to
Wouter> assume that in such a case everyone can be convinced to
Wouter> postpone the vote by two weeks, *at least*, rather than
Wouter> extend the discussion time by a few days in order to allow
Wouter> the option that hasn't finished gathering enough seconds to
Wouter> finish up and become acceptable to enough people.

I think this is interesting to explore.
It's important to me that there be a maximum time that discussions can
last.
But I am open to the idea of being able to extend the discussion time
because you have k seconds interested in doing so even though you don't
yet have a ballot option.

I'll note that under Russ's proposal, you could do this by proposing a
ballot option like
"We'd like to explore mandating using rpm rather than dpkg, but need a
few days to flesh that out.  We will replace this ballot option before
the vote, but if somehow we don't, vote for this option if you'd like to
give us a chance to frame that in the next discussion."

That's clunky I grant you, and I'm definitely open to the idea that
rather than proposing a ballot option like that, k people could delay
the clock (but not more than the maximum discussion period) in order to
get an option onto the ballot.

Wouter> So what I think is important is to allow for a way to get a
Wouter> short amount of extra time, *once*, in order to finish up a
Wouter> proposed ballot option.

I think what I propose above gives you that.

Wouter> This could be accomplished as follows:


Wouter> The process can be repeated as
Wouter> long as the discussion time has not expired; but, crucially,
Wouter> anyone who seconded a previous extension request cannot
Wouter> second another one (although you can *request* another
Wouter> extension if you want).

Wouter> In practice this would mean that if you have a significant
Wouter> level of support for extending the discussion time, you can
Wouter> probably get the discussion time extended twice, and *maybe*
Wouter> three times if you're lucky, but I think it highly unlikely
Wouter> you'll be able to extend beyond that.

Interesting:-)
I'd have to think hard about whether to rank that proposal above or
below FD.
I prefer Russ's option, but given your goals I agree this sounds like a
good way to achieve them.

Re: Opposing strict time limits

[Richard Laager]

On 10/24/21 2:01 PM, Wouter Verhelst wrote:

6. The project leader may, at any point in the process, set the
discussion period to any length between 1 and 3 weeks, except that
they may not do so in a way that causes the discussion period to end
within 48 hours of when this change is made, unless that would
require them to set a discussion time beyond three weeks.


What is the purpose/intent of the "unless" here? If the discussion 
period is coming right up on (< 48 hours) 3 weeks, can the DPL truncate 
it using this?



10. When a time extension has received the required number of seconds,
 the discussion time is extended to end 72 hours from when the
 extension was first proposed.


This wording might need some tweaking for clarity/anti-abuse. 
Specifically, if I ask for and receive an "extension" when there was 
more than 72 hours left already, what happens?


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Re: Opposing strict time limits

[Wouter Verhelst]

On second thought...

On Sun, Oct 24, 2021 at 06:54:51PM +0200, Wouter Verhelst wrote:
> With this process, we could also default the minimum discussion time to
> be much shorter (say, one week or so); then if there is much to discuss,
> after 6 days or so someone could suggest "we're clearly not there yet,
> let's extend the discussion" and we can extend with this process.

This bit (which was meant to have discussion times as short as possible
by default, allowing to extend things if necessary) is probably a
mistake. The process I wrote down, by design, makes it more difficult as
time goes on to extend the discussion time even further; if I say that I
believe 3 weeks may not be enough in contentious debates (and I still
believe that), then reducing the time to 1 week by default and expecting
it to be extended until 3 weeks have passed is probably not a good idea.

So instead, scratch that bit. What we could do though is allow the DPL
to reduce the discussion time from 3 weeks down to one week (but not
up), and allow this process to be used on top of that if and when
necessary.

I also think now that perhaps allowing someone to propose multiple
extensions (and only limiting seconds) could be a bad idea, so I think
it might be better to limit proposers too. 

In somewhat more formal language, apply the following changes to Russ'
draft (sections that remain unchanged from his draft are skipped below):

---
A.1. Discussion and amendment.

1. The discussion period starts when a draft resolution is proposed and
sponsored. The default discussion period is 3 weeks.

[...]

4. (removed, does not apply; for clarity, the following are not
   renumbered although they would have to be in a final proposal)

[...]

6. The project leader may, at any point in the process, set the
   discussion period to any length between 1 and 3 weeks, except that
   they may not do so in a way that causes the discussion period to end
   within 48 hours of when this change is made, unless that would
   require them to set a discussion time beyond three weeks.

[...]

8. Anyone may propose an extension to the discussion time. These
   extensions may be seconded according to the same rules that apply to
   second new ballot options.

9. As soon as a time extension has received the required number of
   seconds, these seconds are locked in and cannot be withdrawn.

10. When a time extension has received the required number of seconds,
the discussion time is extended to end 72 hours from when the
extension was first proposed. Its proposers and seconders may then
also no longer propose or second any further time extensions for the
same ballot, and any further seconds for the same extension proposal
will be ignored. In case of doubt, the Project Secretary determines
how the time of the original proposal is measured, and how the order
of seconds is determined.
---

I *think* this language also allows the DPL to propose a time extension
once, without any seconders, under 5.1.5, but I'm not sure. I think this
is a good thing, and perhaps we should make that somewhat more explicit.

The language I suggest purposely also allows the DPL to change their
mind: they can reduce the discussion time to one week because they
believe the matter is urgent, but then when there is a lot of discussion
happening, they can decide that one week is not enough and extend it to
two weeks, say. Or they can decide that they don't believe more than one
week is necessary, even if discussion is happening; if other people
disagree, they can then attempt to use this procedure to extend the time
if they believe that is necessary.

(I should also note that, given this is an amendment to an amended
version of the constitution, I haven't yet looked at all the possible
corner cases that this would result in, and so some tweaking might be
required; but at least this gives us something to work from)

Thoughts?

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}


signature.asc
Description: PGP signature

Re: Opposing strict time limits

[Wouter Verhelst]

Hi Sam,

On Sat, Oct 23, 2021 at 12:49:57PM -0600, Sam Hartman wrote:
> However there is one area of agreement, and I'll focus there.
> I agree that if a sufficient part of the project wants to continue the
> discussion, we should be able to do that.
> I just don't see how to accomplish that in a way that is better than
> what Russ proposes without being open to abuse.

Thanks for this message. It caused me to reconsider what I think is most
important, and how to accomplish it.

To me, what matters most is that the ballot is built in a way that makes
it most likely that all the relevant options are represented on the
ballot. Not necessary all the *possible* options -- there will always be
fringe opinions that are not supported by a significant amount of
people, but for those it doesn't really matter whether they're on the
ballot; if you can't even convince a handful of people that an option
should be voted on (let alone whether you *agree* with it), then it's
highly unlikely that that option will carry the vote.

However, the problem I see with strict timings that cannot be extended
in any possible scenario is that we may end up with a situation where
one option cannot be fleshed out entirely due to lack of time. I think
it's unrealistic to assume that in such a case everyone can be convinced
to postpone the vote by two weeks, *at least*, rather than extend the
discussion time by a few days in order to allow the option that hasn't
finished gathering enough seconds to finish up and become acceptable to
enough people.

So what I think is important is to allow for a way to get a short amount
of extra time, *once*, in order to finish up a proposed ballot option.

This could be accomplished as follows:

- If you think you need more time to flesh out a ballot option, you can
  formally request, on the -vote mailinglist, for more time.
- A request for more time can be seconded, with the same requirements in
  terms of number of seconds to get an option on the ballot.
- If the request for more time achieves the required number of seconds,
  then the discussion time will last until a certain amount of time (as
  specified in the constitution) from when the request was made (i.e.,
  the count would *not* start from when the discussion time would
  currently expire).
- The process can be repeated as long as the discussion time has not
  expired; but, crucially, anyone who seconded a previous extension
  request cannot second another one (although you can *request* another
  extension if you want).

In practice this would mean that if you have a significant level of
support for extending the discussion time, you can probably get the
discussion time extended twice, and *maybe* three times if you're lucky,
but I think it highly unlikely you'll be able to extend beyond that.

The thought process behind requiring the same level of support for a
time extension as compared to adding an option to the ballot is that
this way, someone could say "I like this proposal, but there are some
details that I would like to see changed before I am prepared to
formally support it". If there's only a limited amount of people who
feel that way, then wordsmithing is unlikely to result in a text that
will satisfy enough people to result in an extra ballot option. However,
if there are, then such an option does have a fighting chance of making
it on the ballot, and I think we should give the people advocating for
that option sufficient time to get there.

In order to make this process work, the time of a single extension
should be long enough so that a person who requests the extension has
sufficient time to go to bed, wake up, go to work, come home, eat, draft
their proposed ballot option, post it to this list, and then have
sufficient time to allow for people to second it. That means that 24
hours is certainly going to be too short, but a full week is probably
going to be too much. I would suggest 72 hours at this point, but I'm
not married to that number.

With this process, we could also default the minimum discussion time to
be much shorter (say, one week or so); then if there is much to discuss,
after 6 days or so someone could suggest "we're clearly not there yet,
let's extend the discussion" and we can extend with this process.

If this process (or something similar) were to be incorporated in the
current draft, my objections to it would vanish.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}


signature.asc
Description: PGP signature

Re: Opposing strict time limits

[Richard Laager]

On 10/23/21 1:49 PM, Sam Hartman wrote:

I agree that if a sufficient part of the project wants to continue the
discussion, we should be able to do that.
I just don't see how to accomplish that in a way that is better than
what Russ proposes without being open to abuse.


I think a great next step would be to see a proposal from Wouter. Maybe 
there is some way. But we need something concrete to really discuss.


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Re: Opposing strict time limits

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:
Wouter> I hear and agree with the argument against such a procedure;
Wouter> having a way to delay the vote which everyone can trigger
Wouter> opens the system up to abuse, which could allow the vote to
Wouter> be delayed indefinitely if formulated badly. I believe the
Wouter> answer to that is not to remove the option to delay the vote
Wouter> entirely, but to restrict the conditions under which such a
Wouter> delay can be invoked; only provide it to the DPL, or provide
Wouter> only a limited number of delays, or allow a majority of
Wouter> people who proposed options that are already on the ballot
Wouter> to object, or something along those lines. The goal should
Wouter> be to end up with a procedure where *can* extend the
Wouter> discussion period if discussions are actually still
Wouter> happening and we believe it is valid, without allowing
Wouter> people who want to avoid any vote from happening entirely to
Wouter> delay things indefinitely.

Wouter> Additionally, this proposal does not remedy what I think is
Wouter> another issue we have with our procedure, which I have been
Wouter> wanting to resolve one way or the other for quite a while
Wouter> but have no idea how to do so; the "I want to create a
Wouter> ballot with all possible options" antipattern.  We had a few
Wouter> cases of this over the years (at least two that I can
Wouter> remember), usually by well-intentioned people who want to
Wouter> get things to a vote quickly, but I honestly believe it
Wouter> creates more problems than it attempts to solve.

Wouter> Writing an option that does not represent your own personal
Wouter> opinion is extremely difficult at best, and is probably not
Wouter> even possible at all.  This means you'll get proposals from
Wouter> people who actually hold an opinion very close to what you
Wouter> wrote down that you'll then need to evaluate to decide
Wouter> whether this improves the ballot option, or whether it
Wouter> changes the option into something different entirely and
Wouter> thus should be a separate ballot option instead. To deal
Wouter> with such a proposal from the point of view of someone who
Wouter> feels one of the options is almost-but-not-quite something
Wouter> you can vote for can be very frustrating, as I experienced
Wouter> first-hand in
Wouter> https://lists.debian.org/debian-vote/2019/11/msg00032.html .

Wouter> I also believe that a ballot with options that were written
Wouter> by people who do not support that option will usually result
Wouter> in a cluttered ballot, with various options that are almost
Wouter> but not quite the same thing, and options that are
Wouter> irrelevant noise and which will never win. I think this
Wouter> behavior should be discouraged if not outright forbidden
Wouter> (although, again, I'm not sure how to forbid them), and
Wouter> would note that adding a strict time limit seems more likely
Wouter> to create private discussions (as I've explained above) and
Wouter> therefore to me seems more likely to result in this
Wouter> antipattern.

Wouter> I'm not submitting a formal draft to go against yours at
Wouter> this point (although I do have the beginnings of one),
Wouter> because I would like to see whether I'm alone in this
Wouter> opinion or not, where only in the latter case it would make
Wouter> sense to continue down this path.

Wouter> Thanks for your thoughts,

Wouter> [1] In the case of 2006-003, I started a discussion on -vote
Wouter> in order to start the debate before formally proposing a GR,
Wouter> intending to explore the problem before starting to build
Wouter> the ballot. The first follow-up to that mail however was a
Wouter> formal GR proposal by Manoj, which then started the
Wouter> procedure. It was not contentious vote though, and I think
Wouter> technically the vote may have expired at least once,
Wouter> although I'm not 100% sure about that -- it involved a few
Wouter> amendments resetting the timer and the DPL extending the
Wouter> minimum discussion period after one of them, so the details
Wouter> are a bit muddy.  [2] In 2006-005, Denis Barbier proposed a
Wouter> vote to recall the project leader. The DPL then delegated
Wouter> the authority to vary the discussion and voting periods to
Wouter> him and Loïc Minier. Denis chose to not accept any
Wouter> amendments and reduced the discussion time to the minimum,
Wouter> and called for a vote while, in my opinion, the discussion
Wouter> was still in full force.

Wouter> -- w@uter.{be,co.za} wouter@{grep.be,fosdem.org,debian.org}


I'm reluctant to engage here, because I disagree strongly with  Wouter,
and I don't think we're going to find consensus, and so at 

Re: Opposing strict time limits

[Wouter Verhelst]

Hi Russ,

On Fri, Oct 22, 2021 at 11:22:36AM -0700, Russ Allbery wrote:
> 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.

I concur -- and to expand on this a bit, I'd like to clarify a bit:

I think we agree that the rules for timing in the current constitution
are a bit messed up. The initial proposer of a GR has powers to affect
the timing that don't strictly belong with that person, and these powers
can be abused. I think we both agree that this needs adjusting.

The difference is in how we would adjust things: your draft proposes to
take that power away entirely, whereas I think a better way forward is
to adjust who can use those powers.

I also don't want to create a situation where the process is fully
unbounded. Currently, effectively everyone can call for a vote at pretty
much any time after a minimal time has passed. I think this is a
feature, not a bug, of our current system, and I want to retain that
feature. I understand that you disagree.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

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