Project Steering Committee

 Date: 02/22/07
 Revision: 1.0.2
 Status: Adopted
 Last Updated: 24/01/2018

Summary

The Project Steering Committee (PSC) is the official governing body of the MapGuide 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 MapGuide 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

The current MapGuide PSC is being rebuilt. The current list of active members is:

• Haris Kurtagic
• Jackie Ng
• Gordon Luckett
• Crispin Hoult
• Trevor Wekel

Past PSC members

• Andy Morsell
• Kenneth Skovhede
• Jason Birch
• Bob Bray (Chair)
• Bruce Dechant
• Tom Fukushima
• Paul Spencer
• Zac Spitzer

Adding Members

Any member of the PSC or the mapguide-internals 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 mapguide-internals mailing list, 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 mapguide-internal mailing list or in an IRC meeting. Motions must be made by a PSC member.
   1. If the motion is made on the mailing list a deadline of 48 hours is assumed. The PSC member may request a longer time frame if they deem it necessary.
   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 48 hours of the meeting minutes being posted and distributed on the mapguide-internals mailing list.
3. PSC members can vote "+1" to indicate support for the motion 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, Project Developers, and election of the chair 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.

MapGuide 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 mapguide-internals mailing list. The author should incorporate and/or respond to all comments received within one week and repost an updated copy of the RFC. The author can begin modifying the RFC in response to feedback after it has been posted for 48 hours. The RFC should not be modified within the first 48 hours to allow everyone a chance to read and provide feedback on the RFC. Once all feedback has been incorporated into the RFC a motion can be brought to the PSC for a vote to either accept or reject the RFC.

An RFC is required when:

• Significant new features are added to the project.
• Changes affect the architecture of the software or component interaction.
• Changes require API, XML schema, or file format modification.
• Changes may impact backward compatibility.
• Changes effect project policies or procedures.
• Changes establishe or effect relationships with external entities such as OSGeo.

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 on the mapguide-internals mailing list and we will decide.

After an RFC has been accepted and as long as the work is not already in a final release, updates to it can be made. These updates are often caused by changes required for implementation. Any updates are posted to the PSC for approval. After 48 hours, if the update is approved, the RFC is updated and an addendum section that describes the update is added.

Responsibilities

The PSC is responsible for all aspects of managing the MapGuide 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

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.

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

• Code Reviews
• Documentation Requirements
• Granting and Revoking Commit Access
• Testing Requirements
• Branch Practice
• Release Schedule (Frequency and Timing)
• Version Numbering

Member Responsibilities

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.

PSC members who are also Project Developers are expected to participate in IRC development meetings. If known in advance that a member cannot attend a meeting, the member should let the other members of the mapguide-internals 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 mapguide-internals IRC meeting minutes.

PSC members are expected to be active on both the mapguide-users and mapguide-internals 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 mapguide-internals mailing list, however they are expected to provide their thoughts and opinions on user level requirements and compatibility issues when RFC discussions take place.