Re: Draft proposal for resolution process change (v2)

[Russ Allbery]

Raphael Hertzog  writes:

> I think we should aim at shortening the voting period too, but likely
> not by much. I would make the voting period last at least 9 days (and no
> more than 14) with a requirement to include two week-ends. Then the
> secretary should have some leeway in fixing the start and the end based
> on his own availability.

Do you think this is something that we should tackle as part of this GR or
as a separate change?  It feels somewhat orthogonal to me.

>> Here is my current draft:

> I saw some interesting discussion about the need to remove the 2:1
> majority requirement to overrule the TC in case the decision has been
> made with the chair casting vote, but I don't see any language for this.

> Is there any reason for this?

I floated the idea but I don't believe anyone has supported the proposal
that I made, and I don't think there's more than one person expressing
support for any other specific proposal.  I was letting the discussion
continue (I owe another response in that thread), but I don't want to add
anything substantive to the GR draft unless there's a fairly clear
consensus in favor of it.  So if folks would like to see this change as
well, please speak up!

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

Re: Draft proposal for resolution process change (v2)

[Russ Allbery]

Bill Allombert  writes:

> I do believe reducing the discussion period gives too much head start to
> the proposing parties, by contrast to others developers that may not
> have allocate time to participate in such discussion at this point of
> the time. This is a matter of fairness.

I completely agree that there is a concern of fairness here (and think it
is exacerbated by the current rules for how to call for a vote).

What do you think of the approach in my current proposal?  The intent
there is to make the minimum period long enough (and also provide a way to
extend it by at least a week by proposing a placeholder ballot option if
need be) to try to remedy this.

I do think that at some point we have to rely on the escape hatch of
campaigning for a "none of the above" vote when the process seems too
rushed, since extending the discussion period indefinitely opens the
opposite problem of a party being able to delay action that the project
wants to take.

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

Re: Draft proposal for resolution process change (v2)

[Bill Allombert]

On Sun, Oct 10, 2021 at 12:01:35PM -0700, Russ Allbery wrote:
> Having closely followed a bunch of GRs now, my personal impression is that
> almost all of the substantitive discussion happens in the first week.
> Some discussion continues into the second week, and for controversial GRs
> a few more options are drafted then.  With the systemd GR, the final
> option that made the ballot was proposed just shy of the three week mark,
> admittedly forced by the vote timing.  (For whatever it's worth, that last
> option was also the only option to not beat further discussion, but there
> was another option proposed a day earlier that did much better.)

I do believe reducing the discussion period gives too much head start to
the proposing parties, by contrast to others developers that may not
have allocate time to participate in such discussion at this point of
the time. This is a matter of fairness.

I also believe that the systemd GR was too atypical to serve as an example.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Draft proposal for resolution process change (v2)

[Raphael Hertzog]

Hi,

thank you Russ for driving this discussion forward. I'm pretty happy
with your proposal.

On Tue, 05 Oct 2021, Russ Allbery wrote:
> I'm somewhat surprised that there has been no discussion of the timing of
> the GR discussion period, which I expected to be more controversial.  The
> scheme I'm proposing is relatively complex but allows the discussion
> period to vary from 1 week to 4 weeks based on how much ballot option
> activity there is and based on DPL actions.  If anyone is unhappy with
> that (if, for example, you think it's too complex or 4 weeks is too short
> or too long), now would be a good time to bring that up so that we can
> discuss it.

On the topic of the length of the discussion period, your proposal tries
to keep the current spirit while adding some safeguards. I think it's
good.

When I try to think of possible simplifications with a fixed period
of discussion, I end up wanting special cases...

For example, I find a fixed 3 week period very long, but if we opt for
that maybe we can authorize an early call for vote (by one of the proposer
or by the DPL) if no changes to the ballot options happened in the last 5
days. That way if a discussion dies after one week, we can still shorten
it to 2 weeks. In practice, it's realy close to your proposed system with
min and max so in the end I concluded that it's not worth exploring that...

Thus the only simplification that is acceptable to me is possibly to get
rid of the DPL power to vary the discussion period. But then the existence
of min and max period avoids most of the problem that could be introduced
by this power.

I think we should aim at shortening the voting period too, but likely not
by much. I would make the voting period last at least 9 days (and no more
than 14) with a requirement to include two week-ends. Then the secretary
should have some leeway in fixing the start and the end based on his own
availability.

> Here is my current draft:

I saw some interesting discussion about the need to remove the 2:1
majority requirement to overrule the TC in case the decision has been made
with the chair casting vote, but I don't see any language for this.

Is there any reason for this?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS