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

Re: [dissenting]: Proposal: Enhance requirements for General resolutions

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

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


> 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

Reply to: