Wouter Verhelst <wouter@debian.org> wrote on 22/11/2021 at 16:15:34+0100: > [[PGP Signed Part:No public key for 2DFC519954181296 created at 2021-11-22T16:15:27+0100 using RSA]] > I propose the following amendment. I expect Russ to not accept it, and > am looking for seconds. > > Rationale > ========= > > Much of the rationale of Russ' proposal still applies, and indeed this > amendment builds on it. However, the way the timing works is different, > on purpose. > > Our voting system, which neither proposal modifies, as a condorcet > voting mechanism, does not suffer directly from too many options on the > ballot. While it is desirable to make sure the number of options on the > ballot is not extremely high for reasons of practicality and voter > fatigue, it is nonetheless of crucial importance that all the *relevant* > options are represented on the ballot, so that the vote outcome is not > questioned for the mere fact that a particular option was not > represented on the ballot. Making this possible requires that there is > sufficient time to discuss all relevant opinions. > > Russ' proposal introduces a hard limit of 3 weeks to any and all ballot > processes, assuming that that will almost always be enough, and relying > on withdrawing and restarting the voting process in extreme cases where > it turns out more time is needed; in Russ' proposal, doing so would > increase the discussion time by another two weeks at least (or one if > the DPL reduces the discussion time). > > In controversial votes, I believe it is least likely for all ballot > proposers to be willing to use this escape hatch of withdrawing the vote > and restarting the process; and at the same time, controversial votes > are the most likely to need a lot of discussion to build a correct > ballot, which implies they would be most likely to need some extra time > -- though not necessarily two more weeks -- for the ballot to be > complete. > > At the same time, I am not insensitive to arguments of predictability, > diminishing returns, and process abuse which seem to be the main > arguments in favour of a hard time limit at three weeks. > > For this reason, my proposal does not introduce a hard limit, and > *always* makes it theoretically possible to increase the discussion > time, but does so in a way that extending the discussion time becomes > harder and harder as time goes on. I believe it is better for the > constitution to allow a group of people to have a short amount of extra > time so they can finish their proposed ballot option, than to require > the full discussion period to be restarted through the withdrawal and > restart escape hatch. At the same time, this escape hatch is not > removed, although I expect it to be less likely to be used. > > The proposed mechanism sets the initial discussion time to 1 week, but > allows it to be extended reasonably easily to 2 or 3 weeks, makes it > somewhat harder to reach 4 weeks, and makes it highly unlikely (but > still possible) to go beyond that. > > Text of the GR > ============== > > The Debian Developers, by way of General Resolution, amend the Debian > constitution under point 4.1.2 as follows. This General Resolution > requires a 3:1 majority. > > Sections 4 through 7 > -------------------- > > Same changes as in Russ' proposal > > Section A > --------- > > Replace section A as per Russ' proposal, with the following changes: > > A.1.1. Strike the sentence "The maximum discussion period is 3 weeks". > > A.1.4. Strike in its entirety > > A.1.5. Rename to A.1.4. > > A.1.6. Strike in its entirety > > A.1.7. Rename to A.1.5. > > After A.2, insert: > > A.3. Extending the discussion time. > > 1. When less than 48 hours remain in the discussion time, any Developer > may propose an extension to the discussion time, subject to the > limitations of §A.3.3. These extensions may be seconded according to > the same rules that apply to new ballot options. > > 2. As soon as a time extension has received the required number of > seconds, these seconds are locked in and cannot be withdrawn, and the > time extension is active. > > 3. When a time extension has received the required number of seconds, > its proposers and seconders may no longer propose or second any > further time extension for the same ballot, and any further seconds > for the same extension proposal will be ignored for the purpose of > this paragraph. In case of doubt, the Project Secretary decides how > the order of seconds is determined. > > 4. The first two successful time extensions will extend the discussion > time by one week; any further time extensions will extend the > discussion time by 72 hours. > > 5. Once the discussion time is longer than 4 weeks, any Developer may > object to further time extensions. Developers who have previously > proposed or seconded a time extension may object as well. If the > number of objections outweigh the proposer and their seconders, > including seconders who will be ignored as per §A.3.3, the time > extension will not be active and the discussion time does not change. > > A.3. Rename to A.4. > > A.4. Rename to A.5. > > A.5. Rename (back) to A.6. While I prefer the 3 weeks hard limit, I also second this proposal. -- PEB
Attachment:
signature.asc
Description: PGP signature