Timo Röhling <roehl...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
