RFC1: Project Steering Committee Guidelines

  • date: 2019-10-09
  • author: Tom Kralidis
  • contact: tomkralidis@gmail.com
  • status: adopted
  • modified: 2019-10-26

Summary

This RFC describes the pygeoapi Project Steering Committee (PSC) rules of engagement and decision making process for all aspects of the project.

Examples of PSC responsibilities:

  • ensuring community code of conduct
  • setting the overall development roadmap
  • technical standards and policies (coding conventions, etc.)
  • ensuring a regular release schedule (major and maintenance)
  • reviewing RFCs
  • project infrastructure (issue tracker, source code management, hosting, etc.)
  • formalization with external entities such as OSGeo, OGC (CITE), etc.
  • setting project priorities

In brief the project team votes on proposals on the pygeoapi mailing list. Proposals are available for review for at least two days, and a single veto is sufficient to delay progress though ultimately a majority of members can pass a proposal.

Detailed Process

  • Proposals are written and submitted to the pygeoapi mailing list for discussion and voting, by anyone
  • Proposals need to be available for review for a least two business days before a final decision can be made
  • RFCs can be drafted on the pygeoapi wiki, and once voted on, cast on website at https://pygeoapi.io/development/rfc/xxx
  • Respondants may vote using the following rubric:
  • +1: support the proposal and a willingness to support implementation
  • -1: veto the proposal, but must provide clear reasoning and alternate approaches to resolving issues within the two days
  • -0: mild disagreement, but has no effect
  • 0: no opinion
  • +0: mild support, but has no effect
  • Anyone can comment on proposals, but only PSC member votes will be counted
  • A proposal will be accepted if it receives +2 (including the author) and no vetoes (-1)
  • 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 votes indicating +1 is sufficient to pass it. Note that this is a majority of all committee members, not just those who actively vote
  • Upon completion of discussion and voting the author should announce whether they are proceeding (proposal accepted) or are withdrawing (vetoed)
  • The Chair gets a vote
  • The Chair is responsible for keeping track of who is a member of the PSC. The authoritative and current PSC membership list is maintained at https://pygeoapi.io/community/psc
  • Addition and removal of members from the PSC, including selection of a Chair should be handled as a proposal to the committee
  • The Chair adjudicates in cases of disputes about voting

When is a Vote Required?

  • changes in committee membership
  • significant changes to project infrastructure
  • backward compatibility issues
  • significant feature implementation(s)
  • Changing the inter-subsystem API, or objects
  • Issues of process/procedures
  • Release management
  • Relationships with external entities (OSGeo, OGC, etc.)
  • Anything controversial

Observations

  • The Chair is the ultimate adjudicator if things break down
  • 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
  • It is anticipated that seperate activities will exist to manage conferences, presentations, websites, demos, etc.

Committee Membership

The PSC is comprised of individuals who are:

  • technical contributors
  • documentation and training contributors
  • other prominent members of the pygeoapi community
  • contributors of strategic direction to pygeoapi as an SDI component

Adding Members

Any member of the pygeoapi 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

If for some reason a PSC member is not able to fully participate then they are free to step down. If a member is not active for a period of 12 months then the committee reserves the right to seek nominations to fill that position. PSC members who have stepped down or have been replaced as certainly welcome to return upon nomincation.

Membership Responsibilities

Guiding Development

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 the go ahead to proceed does not mean the members are free of their obligation. PSC members voting +1 for a change request are expected 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 website, technical infrastructure, policies and standards.

Meeting Attendance

PSC members are expected to participate in pre-scheduled Gitter meetings. Initial frequency is set to once a month.

Mailing List Participation

PSC members are expected to be active on the pygeoapi mailing list and Gitter chat. Non-developer members of the PSC are not expected to respond to coding level questions on the pygeoapi mailing list, however they are expected to provide their thoughts and opinions on user level requirements and compatibility issues when RFC discussions take place.

Bootstrapping

Prior to forming the PSC, this RFC must be distributed before the pygeoapi community for review and comment. Any and all substantive comments are encouraged to be discussed via the pygeoapi mailing list or Gitter channel.

Tom Kralidis is declared initial Chair of the PSC.

Initial PSC members are (in alphabetical order):

Voting History

Adopted on 2019-10-26 with +1 from francbartoli, justb4, pvgenuchten, jorgejesus, tomkralidis, kalxas