Wouter Verhelst <w...@uter.be> writes: > .... aaand this should've been signed. Good morning.
> On Tue, Nov 23, 2021 at 09:50:14AM +0200, Wouter Verhelst wrote: >> All this changes my proposal to the below. I would appreciate if my >> seconders would re-affirm that they agree with the changes I propose, >> and apologies for the mess. I think this is at or near the required number of sponsors, so for the sake of formal process clarity, I do not accept this amendment, which means that it will be listed as a separate ballot option on the eventual ballot. Thank you, Wouter, for proposing this! Happy to let the project decide which timing approach we collectively prefer. >> 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 >> -------------------- >> >> Copy from Russ' proposal, replacing cross-references to §A.5 by §A.6, >> where relevant. >> >> Section A >> --------- >> >> Replace section A as per Russ' proposal, with the following changes: >> >> A.1.1. Replace the sentence "The minimum discussion period is 2 weeks." >> by "The initial discussion period is 1 week." 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.3.6 (now A.4.6): replace 'A.3.4' by 'A.4.4'. >> >> A.4. Rename to A.5. >> >> A.4.2 (now A.5.2): replace '§A.5' by '§A.6'. >> >> A.5. Rename (back) to A.6. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
signature.asc
Description: PGP signature
