| 1 | = RFC 1: Project Management Committee Guidelines = |
| 2 | |
| 3 | Author: Frank Warmerdam[[BR]] |
| 4 | Contact: warmerdam@pobox.com[[BR]] |
| 5 | Status: Adopted |
| 6 | |
| 7 | == Summary == |
| 8 | |
| 9 | This document describes how the GDAL/OGR Project Management Committee |
| 10 | determines membership, and makes decisions on GDAL/OGR project issues. |
| 11 | |
| 12 | In brief the committee votes on proposals on gdal-dev. Proposals are |
| 13 | available for review for at least two days, and a single veto is sufficient |
| 14 | to delay progress though ultimately a majority of members can pass a proposal. |
| 15 | |
| 16 | == Detailed Process == |
| 17 | |
| 18 | 1. Proposals are written up and submitted on the gdal-dev mailing list for discussion and voting, by any interested party, not just committee members. |
| 19 | 2. Proposals need to be available for review for at least two business days before a final decision can be made. |
| 20 | 3. Respondents may vote "+1" to indicate support for the proposal and a willingness to support implementation. |
| 21 | 4. Respondents may vote "-1" to veto a proposal, but must provide clear reasoning and alternate approaches to resolving the problem within the two days. |
| 22 | 5. A vote of -0 indicates mild disagreement, but has no effect. A 0 indicates no opinion. A +0 indicate mild support, but has no effect. |
| 23 | 6. Anyone may comment on proposals on the list, but only members of the Project Management Committee's votes will be counted. |
| 24 | 7. A proposal will be accepted if it receives +2 (including the proposer) and no vetos (-1). |
| 25 | 8. If a proposal is vetoed, and it cannot be revised to satisfy all parties, then it can be resubmitted for an override vote in which a majority of all eligible voters indicating +1 is sufficient to pass it. Note that this is a majority of all committee members, not just those who actively vote. |
| 26 | 9. Upon completion of discussion and voting the proposer should announce whether they are proceeding (proposal accepted) or are withdrawing their proposal (vetoed). |
| 27 | 10. The Chair gets a vote. |
| 28 | 11. The Chair is responsible for keeping track of who is a member of the Project Management Committee. |
| 29 | 12. Addition and removal of members from the committee, as well as selection of a Chair should be handled as a proposal to the committee. The selection of a new Chair also requires approval of the OSGeo board. |
| 30 | 13. The Chair adjudicates in cases of disputes about voting. |
| 31 | |
| 32 | == When is Vote Required? == |
| 33 | |
| 34 | * Anything that could cause backward compatibility issues. |
| 35 | * Adding substantial amounts of new code. |
| 36 | * Changing inter-subsystem APIs, or objects. |
| 37 | * Issues of procedure. |
| 38 | * When releases should take place. |
| 39 | * Anything that might be controversial. |
| 40 | |
| 41 | == Observations == |
| 42 | |
| 43 | * The Chair is the ultimate adjudicator if things break down. |
| 44 | * The absolute majority rule can be used to override an obstructionist |
| 45 | veto, but it is intended that in normal circumstances vetoers need to be |
| 46 | convinced to withdraw their veto. We are trying to reach consensus. |
| 47 | |
| 48 | == Bootstrapping == |
| 49 | |
| 50 | Frank Warmerdam is declared initial Chair of the Project Management Committee. |
| 51 | |
| 52 | Daniel Morissette, Frank Warmerdam, Andrey Kiselev and Howard Butler are |
| 53 | declared to be the founding Project Management Committee. |
| 54 | |