[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Draft proposal for resolution process change (v2)

Timo Röhling <roehling@debian.org> writes:

> In a sense, the GR is the Ultimate Weapon for large-scale decisions
> beyond the scope of a single maintainer, a group of maintainers, or any
> other constitutional entity. As such, I regard a certain cumbersomeness
> as a feature, not a bug. I believe it is more important to have a
> well-understood, very predictable process that ensures all voices are
> heard, even if it sacrifices flexibility. We already have the DPL and
> other delegated teams to deal with more urgent issues.

> I'd prefer a fixed N week discussion period for some reasonable N over
> any scheme that depends on DD oder DPL actions and may easily become
> subject to rule gaming. At the most, I would add a provision to extend
> the discussion period under certain circumstances if N is relatively
> small. This way, any DD can anticipate the voting period well in advance
> and adjust their personal schedule accordingly to make sure they can
> vote if the issue is important to them.

This is an excellent statement of the argument that I personally lean
towards.  I know other folks feel more strongly than I do about giving the
DPL, or at least the project, some flexibility to deal with more urgent
issues or to let things take a bit longer, so I left this part in.  But I
have to admit that if I were writing the constitution purely for myself, I
would set the discussion period at a fixed three weeks and remove all the
complexity for varying it.

Currently, the DPL can vary the minimum discussion period and the voting
period by up to one week each, which puts the time required to make a
decision by GR at an absolute lower bound of two weeks right now.  That's
already fairly long for anything urgent.

I don't recall how often the DPL has varied the voting period.  My
possibly erroneous recollection is that this has rarely happened, which
increases the minimum time period to three weeks in practice.  This is now
quite long for anything that's actually urgent.

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.)

Three weeks therefore seems like a good time period to pick.  It felt like
it was long enough, at least to me, for one of the most complex and
controversial GRs to get a ballot that was reasonably comprehensive, and
it was also the point at which a lot of the project was sick of the
discussion and had largely tuned it out, which will result in reducing
quality of discussion for anything proposed after that point.  There's
always going to be an argument for taking a bit longer, but I think it's
worth taking into account people's attention span and recognizing that
we're never going to get a perfect GR.

I'm not sure that it makes much difference whether we decide things in
five weeks or four weeks, but the first place I'd look to shorten the
process further would be to fix the voting period at one week instead of
leaving it to the DPL to vary, since two weeks always feels like a very
long voting period.  I believe we do get a substantial number of votes in
the second week, though, so perhaps that's not a good idea.  (Two weeks
does provide some generous flexibility around people's vacations.)

All that being said, I know other folks have strong opinions about having
some flexibility and about three weeks being too short, so I was hoping
they would weigh in here.

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

Reply to: