Hi,

First,

Many thanks to Russ and Wouter for all their work on this.

+1


If I understand correctly, most agree that we would like to keep
the discussion period short in most cases. But at the same time, in
exceptional circumstances, some would like a way to extend it.

Instead of the quite complex procedure proposed by Wouter, couldn't we
patch the DPL's power to increase or decrease the the discussion period
to allow the DPL to extend it beyond three weeks?

The change could be as simple as replacing 'original values in point
A.1.1' with 'former values' in

The Project Leader may, at any point in the process, increase or
decrease the minimum and maximum discussion period by up to 1 week from
their original values in point A.1.1, 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. The length of the discussion period is then
recalculated as if the new minimum and maximum lengths had been in place
during all previous ballot changes under points A.1.1 and A.1.4.

I think that it is reasonable to assume that the DPL will make such
decisions based on what is best for the project. If the DPL abuses this, there's still the possibility to override the decision.

There could be a loophole if the DPL extends indefinitely a GR to recall
the DPL or to override the DPL, so maybe those should be excluded
though.

Lucas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Wouter Verhelst <wouter@debian.org> writes:

On Mon, Nov 29, 2021 at 08:55:19PM +0100, Lucas Nussbaum wrote:

Instead of the quite complex procedure proposed by Wouter, couldn't we
patch the DPL's power to increase or decrease the the discussion period
to allow the DPL to extend it beyond three weeks?

The downside of doing that is that if the DPL does this, then it is a
fairly political action, with all downsides of that method: if there is
a group of developers who would like the time to be extended and a group
who doesn't, then the DPL will be caught between a rock and a hard
place, and will be yelled at by one group or the other, regardless of
which decision they take.

Yes, this exactly. When drafting my original proposal, I thought about
this possibility, but I think it puts the DPL in an incredibly difficult position where they will be accused of political bias no matter what they
do.

I have mostly convinced myself that there are only two good options for handling the discussion period length that won't cause other problems or
put people into difficult positions: setting a pretty tight minimum and maximum, with a bit of flexibility given to the DPL and to give people a
chance to absorb new proposals but not enough to be abused or to provoke
more than a bit of minor grumbling; or having a vote of some type on when
to end the discussion period.

On the current ballot, both of those are represented. My option sets a
pretty tight range of options for the discussion length (one to four
weeks), and Wouter's system has a rather elegant, if a bit complex, voting system. That seems like a good set of options to choose between.

I think that it is reasonable to assume that the DPL will make such
decisions based on what is best for the project. If the DPL abuses
this, there's still the possibility to override the decision.

But then you now have two votes, which feels superfluous.

Also, the process for the DPL vote override is kind of a mess. I didn't
try to fix that because this proposal is already doing enough, but then
you have a vote that lasts (presumably) two weeks, about whether to extend
the discussion period of another vote, and edge cases abound. For
example, it's entirely possible that the vote on whether to override the
DPL decision to not extend the voting period could finish well after the
voting period for the original GR had started.

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Nov 29, 2021 at 08:55:19PM +0100, Lucas Nussbaum wrote:

Hi,

First,

Many thanks to Russ and Wouter for all their work on this.

+1

If I understand correctly, most agree that we would like to keep
the discussion period short in most cases. But at the same time, in exceptional circumstances, some would like a way to extend it.

Instead of the quite complex procedure proposed by Wouter, couldn't we
patch the DPL's power to increase or decrease the the discussion period
to allow the DPL to extend it beyond three weeks?

The downside of doing that is that if the DPL does this, then it is a
fairly political action, with all downsides of that method: if there is
a group of developers who would like the time to be extended and a group
who doesn't, then the DPL will be caught between a rock and a hard
place, and will be yelled at by one group or the other, regardless of
which decision they take.

The proposed system makes it less problematic in that respect: the DPL
still has the ability to extend the discussion time by themselves once,
but really the responsibility of extending the discussion time is now in
the hands of the people who are actually discussing things.

[...]

I think that it is reasonable to assume that the DPL will make such
decisions based on what is best for the project. If the DPL abuses this, there's still the possibility to override the decision.

But then you now have two votes, which feels superfluous.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Russ" == Russ Allbery <rra@debian.org> writes:

Russ> Wouter Verhelst <wouter@debian.org> writes:
>> On Mon, Nov 29, 2021 at 08:55:19PM +0100, Lucas Nussbaum wrote:

>>> Instead of the quite complex procedure proposed by Wouter,
>>> couldn't we patch the DPL's power to increase or decrease the
>>> the discussion period to allow the DPL to extend it beyond three
>>> weeks?

>> The downside of doing that is that if the DPL does this, then it
>> is a fairly political action, with all downsides of that method:
>> if there is a group of developers who would like the time to be
>> extended and a group who doesn't, then the DPL will be caught
>> between a rock and a hard place, and will be yelled at by one
>> group or the other, regardless of which decision they take.

Russ> Yes, this exactly. When drafting my original proposal, I
Russ> thought about this possibility, but I think it puts the DPL in
Russ> an incredibly difficult position where they will be accused of
Russ> political bias no matter what they do.

Strongly agreed. I was trying very carefully to use this DPL power
during the systemd resolution to make the options I proposed work like
options others proposed. Even that accumulated a fair bit of
frustration.
Giving this power to the DPL makes the DPL job more challenging,
especially if the DPL is actually trying to lead and proposing ballot
options that are in the middle.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)