GSIP 141

GSIP 141 - Change GSIP voting rules from majority to three positive votes

Overview

Proposed By

Ben Caradoc-Davies

Assigned to Release

This proposal affects all GeoServer Improvement Proposals.

State

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

Motivation

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.

Proposal

• Change the GSIP voting rules so that a GSIP is accepted if it receives three "+1" votes and no "-1" votes.

• Minor language clarifications for "+0"/"0"/"-0" votes, which all have no impact on voting but permit PSC members to have their vote and opinion recorded and express their active status.

Discussion

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

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

Voting

Project Steering Committee:

• Alessio Fabiani:
• Andrea Aime:
• Ben Caradoc-Davies:
• Christian Mueller:
• Ian Turton:
• Jody Garnett:
• Jukka Rahkonen:
• Kevin Smith:
• Simone Giannecchini:

Links

• Mailing list discussion "GSIP 141 - Change GSIP voting rules from majority to three positive votes"
• Mailing list discussion "GSIP-136 Resource Notification Dispatcher"
• GeoTools / GeoServer Meeting 2016-03-08