Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes: > I have to disapprove on a proposal whose purpose is essentially to > disfranchise developers from their right related to general > resolutions. This proposed change disenfranchises no-one; no-one's rights are deprived. It does not discriminate and treats all DDs equally (as does the status quo). > General resolutions are a much more democratic and mature processes > to handle conflicts than massive flamewars that unfortunately are > occasionally seen on our lists. Yes, they're an essential tool. The proposal, AFAICT, does not seek to change that fact. > Restricting them is not going to help the project. Increasing the bar for a proposed option to enter the ballot is respectful of the time of all DDs. I think that certainly would help the project, and I think the current proposal would help achieve that. No restriction is proposed on *what* can be proposed for a GR; only that GR proposals must show they meet a higher threshold of support before going to a vote. If a proposal can't even garner seconds from floor(Q) DDs, I think it certainly does help the project to keep such a proposal off the ballot. > Secondly, the GR process depends heavily on the possibility of > developers to offer amendments and extra options on the ballots. In > particular it is vital that middle-ground options get on the ballot. > Requiring of them a high number of seconds might bar them from being > on the ballot, because they are not preferred options, but > compromises. This I find more interesting. I'll reserve opinion on this until I see what counter-arguments are made. > To set an example, are you willing to refrain to call for vote this > GR until you get at least 30 seconds ? That's a fair question, but AUIU, it is not up to the proposer, having already proposed, to decide when the vote gets called. > I am afraid this GR will be inefficient to reach its objective > (which I disapprove of): > > 1) It does not limit the number of GR proposal which will be made, > only the number that will be callable for vote. Which, I predict, will weed out those proposals that do not have sufficient support from interested parties to garner a significant vote tally. That seems only a good thing. > 2) This will reduce the standard for seconding GR proposals. How? > 3) It can be worked around by a set of 25 developers that would just > seconds any GR proposal made, even if they plan to vote against. The same could be said for the current system: a hypothetical cabal of merely 5 developers could ensure that every proposal gets through by doing exactly as you say. Yet apparently this has not happened. Why would 25 such developers begin acting that way if 5 have not? -- \ “He that would make his own liberty secure must guard even his | `\ enemy from oppression.” —Thomas Paine | _o__) | Ben Finney
Attachment:
pgpZzKEiAVyK6.pgp
Description: PGP signature