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.
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.
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.
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.
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.
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.
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.
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 ProceduresThe PSC is responsible for defining the policies and procedures for the FDO Open Source project, including:
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 AttendancePSC 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 ParticipationPSC 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.