FDO Open Source - Project Steering Committee [DRAFT]

Summary

The Project Steering Committee (PSC) is the official governing body of the FDO Open Source Project and is responsible for all aspects of managing the project. The PSC is made up of individuals based on merit and is responsible for setting the overall direction of the project and releases, determining what features go in and when, and how those features are implemented. As a user or developer this document provides insight into how the project is managed and how you can enhance and influence it. In particular this document describes the structure of the PSC, the process by which is makes decisions on project issues (both technical and non-technical), and the responsibilities of the PSC and its members.

The definition of the FDO Open Source PSC derives from the guidelines already developed for the MapServer Technical Steering Committee, the GeoServer PSC, and the MapBuilder PSC.

Structure

The PSC is made up of individuals consisting of developers and users. Members are elected to participate in the PSC based on merit irrespective of their organizational ties. It is desirable but not strictly required for the PSC to be made up of an odd number of members (5 or more) to prevent ties in the voting process. One member of the PSC is appointed Chair, who has additional responsibilities to organize regular meetings and to resolve tie votes should they occur. The Chair is the ultimate adjudicator should the process ever breakdown entirely.

Current PSC

Adding Members

Any member of the PSC or the FDO-dev mailing list may nominate someone for committee membership at any time. Only existing PSC members may vote on new members. Nominees must receive a majority vote from existing members to be added to the PSC.

Stepping Down

Turnover within the PSC is allowed and expected as people move from one project to another or simply move on to a different role. If for any reason a PSC member is not able to fully participate then they are free to step down. If a member is not active (e.g. no voting, mailing list, or IRC participation) for a period of two months then the PSC reserves the right to remove that member from the PSC via a motion from a PSC member and a majority vote. Likewise should a member of the PSC begin to act counter to the goals of the project as a whole on a recurring basis, then a PSC member can raise a motion to remove that member from the PSC. Again in this case a majority vote is required to pass the motion thus removing that member from the PSC. In both cases the PSC is then free to seek nominations to fill that position.

Process

The primary role of the PSC is to make decisions relating to the management of the project. The decision making process is based on reaching democratic consensus by having open discussion followed by a vote.

  1. Proposals can be brought forth by any interested party on the fdo-psc or fdo-dev mailing lists, or in an IRC meeting. Depending on what is being proposed it may be informal (e-mail or IRC description sufficient) or based on an RFC. After open discussion of the proposal, a motion to vote on it must be made within one week.
  2. All voting is based on a motion made either on the fdo-psc mailing list or in an IRC meeting.
    1. If the motion is made on the mailing list a deadline of at least two working days and preferably one week must be given.
    2. If the motion is made in an IRC meeting there must be a 2/3 quorum in attendance in order to vote. Members not present can still veto within 24 hours of the meeting minutes being posted and distributed on the fdo-psc mailing list.
  3. PSC members can vote "+1" to indicate support for the change request and a willingness to support implementation.
  4. PSC members can vote "-1" to veto a proposal, but must provide clear reasons and alternate approaches to solving the problem.
  5. A "-0" vote indicates mild disagreement but has no effect, a "0" vote indicates no opinion, and a "+0" indicates mild support but has no effect.
  6. Anyone may comment or provide input to motions, but only PSC member votes will be counted.
  7. A motion will be accepted if it receives "+2" (including the proposer if applicable) and no veto's "-1".
  8. If a motion 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 PSC members must vote "+1" in order to pass it.
  9. Upon completion of the discussion and voting the proposer should announce whether they are proceeding (motion accepted) or are withdrawing their motion (vetoed).
  10. Addition and removal of PSC members and Project Developers is handled as a motion, however a majority vote is required in these cases.
  11. The Chair gets a vote and is responsible for adjudicating should there be a voting dispute.

FDO RFCs

RFCs are more formal documents that are required for significant technology, process, or political changes to the project. They typically include both the motivation behind the proposal and a detailed description of the change. Any interested party can write an RFC not just PSC members and developers. Once written they are posted to the project site and an announcement made to the fdo-psc mailing list. Technical RFCs should also be announced on the fdo-dev mailing list. The author should incorporate and/or respond to all comments recieved within one week and repost an updated copy of the RFC. At that point a motion can be brought to the PSC for a vote to either accept or reject the RFC.

An RFC is required when:

An RFC is not required for bug fixes or minor enhancements that do not rework any substantial amount of code. After reading this if you are not sure whether an RFC is required or not, ask the PSC via e-mail and we will decide.

Responsibilities

The PSC is responsible for all aspects of managing the FDO Open Source project including setting the overall direction of the project and releases, determining what features go in and when, and how those features are implemented. This section outlines the responsibilities of the PSC as a whole and responsibilities of its members.

Committee Responsibilities


Feature Development and Release Management

The PSC is responsible for defining the project roadmap, deciding which new features and significant code changes are accepted into the project, and into which release the change will appear. Deciding what features are accepted and when is a multi-faceted decision, but the roadmap will always have a strong influence. New project features and/or functionality is proposed to the PSC via an RFC. Once the request is submitted, the PSC uses the decision making Process to decide if the change will be accepted and which release it will go into. In addition the PSC determines when a branch enters the stabilization phase and ultimately when it is ready for release.

Project Policies and Procedures

The PSC is responsible for defining the policies and procedures for the FDO Open Source project, including:

Member Responsibilities


Guiding Development Efforts

PSC members should take an active role guiding the development of new features they feel passionate about. Once a change request has been accepted and given a green light to proceed does not mean the PSC members are free of their obligation. PSC members voting "+1" for a change request are expected to to stay engaged and ensure the change is implemented and documented in a way that is most beneficial to users. Note that this applies not only to change requests that affect code, but also those that affect the web site, procedures, and policies.

Weekly IRC Meeting Attendance

PSC members who are also Project Developers are expected to participate in the weekly IRC development meeting. If known in advance that a member cannot attend a meeting, the member should let the other members of the fdo-dev e-mail alias know via e-mail. Continuously missing the IRC meeting may result in the member being asked to step down to make way for a more active member. Non Project Developer PSC members are expected to review the fdo-dev IRC meeting minutes.

Mailing List Participation

PSC members are expected to be active on both the user and developer mailing lists, subject to open source mailing list etiquette. Non-developer members of the PSC are not expected to respond to coding level questions on the developer mailing list, however they are expected to provide their thoughts and opinions on user level requirements and compatibility issues when Change Request discussions take place.