= RFC 1: Project Steering Committee Guidelines = Author: Frank Warmerdam[[BR]] Contact: warmerdam@pobox.com[[BR]] Status: Development == Summary == This document describes how the OSGeo4W Project Steering Committee determines membership, and makes decisions on OSGeo4W project issues. In brief the committee votes on proposals on osgeo4w-dev. Proposals are available for review for at least two business days, and a single veto is sufficient to delay progress though ultimately a majority of members can pass a proposal. == Detailed Process == 1. Proposals are written up and submitted on the osgeo4w-dev mailing list for discussion and voting, by any interested party, not just committee members. 2. Simple proposals like adding members to the committee will be known as motions and can be handled entirely on the mailing list. 3. Policies and complex proposals will be written in the [wiki:RFCs trac wiki] as an RFC (like this policy), so a permanent, accessible record exists. 4. Proposals need to be available for review for at least two business days before a final decision can be made. 5. Respondents may vote "+1" to indicate support for the proposal and a willingness to support implementation. 6. Respondents may vote "-1" to veto a proposal, but must provide clear reasoning and alternate approaches to resolving the problem within the two days. 7. 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. 8. Anyone may comment on proposals on the list, but only members of the Project Steering Committee's votes will be counted. 9. A proposal will be accepted if it receives +2 (including the proposer) and no vetos (-1). 10. 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. 11. Upon completion of discussion and voting the proposer should announce whether they are proceeding (proposal accepted) or are withdrawing their proposal (vetoed). 12. The Chair gets a vote. 13. The Chair may extend the voting time on any proposal to one calendar week (to ensure time to review). 14. The Chair is responsible for keeping track of who is a member of the Project Steering Committee. 15. 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 confirmation of the OSGeo board. 16. The Chair adjudicates in cases of disputes about voting. == When is an RFC Required? == * Issues of procedure and policy that will apply to the whole project. * Changes results in significant backward compatibility effects. * Major changes in technology choices (ie. adding a 64bit version, using a new packaging technology) * Anything that might be controversial. == Observations == * The Chair is the adjudicator in cases of confusion. * The OSGeo board may replace the chair in situations of extreme disfunction. * The absolute majority rule can be used to override an obstructionist veto, but it is intended that in normal circumstances vetoers need to be convinced to withdraw their veto. We are trying to reach consensus. == Bootstrapping == Jürgen E. Fischer is declared initial Chair of the Project Steering Committee. Jürgen E. Fischer, Matt Wilkie, Paolo Cavalini, Tamas Szekeres are declared to be the founding Project Steering Committee. The current membership list can be found on the [wiki:CoreTeam Core Team] page (but identified distinctly from other core team members).