GSIP 141
Ben Caradoc-Davies
This proposal affects all GeoServer Improvement Proposals.
- Under Discussion
- In Progress
- Completed
- Rejected
- Deferred
As the GeoServer Project Steering Committee has grown in size, the GSIP voting rules have had an unintended consequence: a GSIP with several supporters can be defeated by the "0" votes of well-meaning PSC members expressing their lack of concern. For example, voting for "GSIP-136 Resource Notification Dispatcher" resulted in the initial defeat of the proposal by "0" votes that diluted the required majority. The initial vote had four "+1" votes and the GSIP would have passed if two of those voting "0" had simply failed to vote.
The problem with the current GSIP voting rules is that, because every PSC member has a conditional veto ("-1" vote), negative votes are never considered in the calculation of a majority, so the vote becomes a contest between supporters and those not opposed to the GSIP, which is an absurd consequence that does not seem to be understood by PSC members nor intended by the committee.
Change the GSIP voting rules so that:
-
Only active PSC members are counted for voting purposes.
-
A GSIP is accepted if it receives:
- 30% "+1" votes, and
- a quorum of 50% "+1"/"+0"/"0"/"-0" votes, and
- no "-1" votes.
-
"+0"/"0"/"-0" votes are all permitted and have the same effect.
-
Voting remains open for seven days or until all active PSC members have cast their vote.
-
Any active PSC member can during these seven days request an extension of voting for an additional seven days. The voting period can only be extended once.
-
One advantage of the current rule is that the need to obtain a majority of positive votes is a barrier to GSIPs that do not offer significant improvements to GeoServer. This might reduce the cruft included in the project and increase focus. PSC members will need to consider whether this is an advantage or whether cruft is better managed in the community module process.
-
The problem of vote dilution has arisen through the increase in PSC size and activity. The change in voting rules reduces the threshold required for a GSIP to that required for a smaller PSC. The purpose of the increase in PSC size was to increase representation and the number of workers, not to increase the work required to pass each GSIP (assuming "+1" votes are each based on a substantive review).
-
Three "+1" votes is similar to the process for granting GeoTools commit access.
From: GeoTools / GeoServer Meeting 2016-03-08
GeoServer Discussion:
- PSC responsible for maintaining core and need some way of regulating content.
- Ignored proposals should not be accepted.
- Pull requests abandoned by proposers are also a problem.
- Huge pull requests before discussion are an additional problem.
- Problem of late discovery of API change needed for huge pull request.
- How about a percentage of the PSC? 30% of +1 votes: ceil(0.3*size(psc))
- Jody has horrific alternative from OSGeo board of math
- Stagnation problem
- Support for PSC member requiring additional one week delay
- With GitHub, commit access is no longer as important.
GeoTools Discussion:
- 3 day for svn access :) --> ask for a feature branch on the central github.
- 10 days and your are approved --> do we switch to quorum? no quorum, no party.
Jody is hesitant on switching to "30% positives/50% quorum/no -1" as GeoTools PMC is less responsive. Quorum is taken as 100% active as PMC members are automagically retired :D
For a serious formula, see here: http://mathb.in/53467 or http://mathb.in/53468
Project Steering Committee:
- Alessio Fabiani:
- Andrea Aime: +1
- Ben Caradoc-Davies: +1
- Brad Hards: +1
- Christian Mueller: +1
- Ian Turton: +1
- Jody Garnett: +1
- Jukka Rahkonen: +1
- Kevin Smith: +1
- Simone Giannecchini: +1
©2022 Open Source Geospatial Foundation