GPII Technical Governance

From wiki.gpii
Jump to: navigation, search

Overview

The Global Public Inclusive Infrastructure is built and supported by an open source community governed as a meritocracy. Influence and authority is distributed amongst both volunteer and employed community members based on their skill and contributions to the project.

This technical governance process is intended to provide clear, simple, and collaborative "rules of the game" for contributing to the GPII, making decisions, and earning commit access. This policy covers the core open source software developed by GPII-affiliated projects. Recognizing that other communities have extensive experience with open governance, this policy adopts many of the approaches used by prominent open source projects, including:

Inclusion Policy

In order to support safe and constructive collaboration amongst all contributors, the GPII has adopted Mozilla's Inclusion and Diversity policy. In summary, the Global Public Inclusive Infrastructure...

...welcomes and encourages participation by everyone. It doesn’t matter how you identify yourself or how others perceive you: we welcome you. We welcome contributions from everyone as long as they interact constructively with our community, including, but not limited to people of varied age, culture, ethnicity, gender, gender-identity, language, race, sexual orientation, geographical location and religious views.

The GPII has also adopted Mozilla's interaction style for communications amongst community members. This includes:

  • Be respectful. We may not always agree, but disagreement is no excuse for poor manners. We will all experience some frustration now and then, but we don’t allow that frustration to turn into a personal attack. A community where people feel uncomfortable or threatened is not a productive one.
  • Try to understand different perspectives. Our goal should not be to "win" every disagreement or argument. A more productive goal is to be open to ideas that make our own ideas better. "Winning" is when different perspectives make our work richer and stronger.
  • Do not threaten violence.
  • Empower others.
  • Strive for excellence. Our products must be great and our communities must be healthy and vigorous. Being respectful does not mean papering over disagreements or accepting less than we can do.
  • Don’t expect to agree with every decision.


Suggestions for handling conflicts (also from Mozilla's guidelines):

  • If you feel comfortable, talk to the person directly
  • Talk with someone in the community you trust to help mediate
  • Engage a committer or other project leadership group member to help resolve the issue


Types of Projects

Core Projects

Core repositories contain production-level code for the GPII. These repositories are fully governed by this technical governance policy and the GPII Technical Standards. In summary, all pull requests must be code reviewed by another committer prior to being included, and pull requests must be accompanied by both unit and integration tests to ensure their long-term viability. Even committers must submit pull requests for review. Core repositories are managed in the GPII GitHub Organization, and only members of the committers team can push changes to these repositories. Contributions and pull requests from anyone are, of course, hugely welcome (and part of the process of earning meritocratic recognition). Core repositories are identified in the #Core Repositories section of this document.

Emerging Projects

Emerging projects are not subject to the same technical governance requirements as core repositories. Emerging repositories can slowly evolve to meet the core standards. These repositories will be free to work more loosely, but a mentor from the committers team will be assigned to help with an "incubation" process whereby the emerging project is expected to eventually grow into the full technical governance standards. Emerging repositories are also managed in the GPII GitHub Organization. When a project is ready to be promoted to core status, a proposal should be made to the list and committers should vote on its inclusion.

Roles

The following project roles are derived from OSS Watch's Meritocratic Governance Model guidelines.

Users

Users are community members who have a need for the project. They are the most important members of the community and without them the project would have no purpose. Anyone can be a user; there are no special requirements. The goal of the GPII is to engage and co-design with users throughout the design and development process.

Contributors

Contributors are community members who contribute in various ways to the project. Anyone can become a contributor, and contributions can take many forms—not just technical. There is no expectation of commitment to the project, no specific skill requirements and no selection process. For example, contributors might:

  • help support new users
  • report or fix bugs
  • identify requirements
  • test the software
  • contribute to the design process
  • contribute code and new feaures
  • assist with project infrastructure
  • write documentation or help "garden" the wiki

Contributors engage with the project through the issue tracker, mailing lists, wiki, IRC channels and source code repositories. They submit changes to the project via pull requests or publicly-published design artifacts (such as wireframes, interaction flow diagrams, or user research findings), which will be considered for inclusion in the project by existing committers. The architecture and UX mailing lists are the most appropriate place to ask for help when making that first contribution.

As contributors gain experience and familiarity with the project, their profile within, and commitment to, the community will increase. At some stage, they may find themselves being nominated for committership.

Committers

Committers are community members who have shown that they are committed to the continued development of the project through ongoing engagement with the community. Committership allows contributors to more easily carry on with their project related activities by giving them access to push code to the project repositories.

This does not mean that a committer is free to do what they want. While committership indicates a valued member of the community who has demonstrated a healthy respect for the project’s aims and objectives, their work continues to be reviewed by the community before acceptance. The key difference between a committer and a contributor is the responsibility to review pull requests and mentor contributors. While contributors are welcome and invited to participate in reviewing code and mentoring others, committers are required to do so.

The project employs various communication mechanisms to ensure that all contributions are reviewed by the community as a whole. By the time a contributor is invited to become a committer, they will have become familiar with the project’s various tools as a user and then as a contributor.

Anyone can become a committer; there are no special requirements, other than to have shown a willingness and ability to participate in the project as a team player. Typically, a potential committer will need to show that they have an understanding of the project, its objectives and its strategy. They will also have provided valuable contributions to the project over a period of time. This process is described in detail below.

New committers can be nominated by any existing committer. Once they have been nominated, there will be a vote by the existing committers. Committer voting is one of the few activities that takes place on the project’s private management list. This is to allow committers to freely express their opinions about a nominee without causing embarrassment.

Nominees may decline their appointment as a committer. However, this is unusual, as the project does not expect any specific time or resource commitment from its community members. The intention behind the role of committer is to allow people to contribute to the project more easily, not to tie them in to the project in any formal way.

It is important to recognise that commitership is a privilege, not a right. That privilege must be earned and once earned it can be removed in extreme circumstances. However, under normal circumstances committership exists for as long as the committer wishes to continue engaging with the project.

Voting

The GPII governance process is directly inspired by the Apache Foundation. In the spirit of not wanting to reinvent the wheel, we have adopted Apache's voting process with a few refinements. In particular, we have not adopted Apache's concept of a Project Management Committee. Instead, all committers are expected to participate in this role. We've tried to keep the process simple and clear, allowing members of the community to play a central role in the process of making decisions about the project.

Types of Proposals

Ordinary day-to-day design and development activities, when done done openly, typically proceed without any requiring any kind of formal procedure. For more substantial issues, there are two types of proposals that can be made in the community:

  1. Lazy consensus proposals
  2. Formal calls for votes

In the first category, a proposal is posted to the mailing list (preferably with a link to the wiki). In these cases, unless a -1 vote is received, work should continue under the assumption of tacit approval. This type of proposal should be reserved for general project activities (such as release planning), not major technical, architectural, governance, or strategic decisions.

For decisions that will have a significant impact on the design, development, or architectural direction of the GPII technologies and our users, a formal vote should be called. We vote formally on technical and design governance issues, major architectural or design changes, substantial changes to the code base, new committers, and so on. Formal votes should typically involve an email to the appropriate mailing list with "[Vote]" in the subject line.

In all cases, voting implies a responsibility. While no one is required to vote, community members are encouraged to contribute if a vote affects an area you have experience in.

Lazy Consensus

From Apache:

Lazy Consensus: A decision-making policy which assumes general consent if no responses are posted within a defined period. For example, 'I'm going to commit this by lazy consensus if no-one objects within the next three days... Essentially lazy consensus means that you don't need to get explicit approval to proceed, but you need to be prepared to listen if someone objects.

Day to day design and development activities (e.g. bug fixes, implementation of planned features, etc.) tend not to require formal voting or proposal-making of any kind as long as they're part of the regular flow of development and done entirely openly. Silence means approval.

In cases where opinions need to be solicited—for example, release planning or roadmapping—a lazy consensus proposal should be posted to the mailing list and typically given 72 hours for people to comment.

Beyond this, in cases where an issue is deemed more substantial than is appropriate for lazy voting, a formal vote on the issue can be called, allowing time for more considered discussion and potential vetoes. See below for more details.

To succeed with lazy consensus-based governance, our community needs to be both open and engaged. Community members need to be informed about the ongoing work of the project (the architecture mailing list and #fluid-work IRC channel are typical venues for communication), and they need to remain aware of and engaged in activities that are relevant to their areas of interest and experience.

Who Can Vote?

Everyone in the community can vote on lazy proposals. Voting implies a commitment to get involved, so please refrain from weighing in on issues that aren't within your area of expertise, or more broadly, within your ability to contribute.

For formal issues, only votes from committers are binding, but community members are nonetheless encouraged to share their thoughts and opinions.

Voting Notation

From Apache:

The voting process in Apache may seem more than a little weird if you've never encountered it before. Votes are represented as numbers between -1 and +1, with '-1' meaning "no" and '+1' meaning "yes."

In the GPII community, we tend to stick with straightforward integer votes expressing approval or disagreement:

Vote Meaning
+1 I support this proposal and am willing to contribute where possible.
0 I don't feel strongly about the issue either way.
-1 I don't agree. Here's what I think we can do to change/improve/rework the idea. For formal votes, -1 vote is a veto.

Apache provides useful documentation about decision making and voting in their wiki.

Negative Votes

While positive votes express support for a particular proposal, a negative vote acts as an immediate veto. This comes with a strong set of associated responsibilities. If you vote -1, you need to also:

  • Explain the rationale for your negative vote.
  • Offer a viable alternative proposal, or describe the steps that need to be taken to change your vote to a +1
  • Be willing to contribute to the process of devising and implementing alternatives

Process for Granting Commit Access

Commit access is intended for people who have shown technical merit within the GPII community.

Prerequisites

Aspiring committers need to earn the trust of the community over a period of time by:

  1. participating in discussions
  2. submitting clear, well-written pull requests for review
  3. meeting the technical standards of the community

See Apache's list of criteria for new committers for more information about the criteria used when voting on new committers. It includes:

  • Ability to work cooperatively
  • Ability to be a mentor
  • Community factors: use of mailing lists and other public forums
  • Commitment
  • Skill and ability

Nominations

A potential new committer is nominated by a member of the committers group. This should be done publicly on the architecture@lists.gpii.net mailing list. Current committers vote privately on the nomination. This allows committers to honestly share their opinions and assess the candidate's suitability and experience. It also avoids hurt feelings and a culture of personal criticism. A private, moderated mailing list, gpii-committers, has been be set up for this purpose.

Voting on Commit Access

Typical voting rules apply:

  • +1 for agreement that the nominee is a suitable candidate for commit access
  • If you vote -1, you must include a rationale and what will be required to change the vote to a +1

Not everyone is required to vote, but if you know the nominee's work and code, you are encouraged to vote. Non-votes will be treated as 0.

The voting period will last for a minimum of a week, or until all current committers have voted.

Negative Votes

One vote of -1 automatically disqualifies a nomination for commit access. The nominee will be informed of the rationale and what they need to do to change the vote to +1 in the future. It is highly recommended that a rejected nominee be paired up with members of the committers team to mentor them into a successful committer.

If a nomination is denied, a member of the committers group will provide an explanation and coach the candidate on how they may earn commit access in the future.

Positive Votes

If the committer is accepted, they will be given access to the GPII's GitHub organization and must follow the responsibilities and expectations that come with commit access, which are described below.


Responsibilities and Expectations for Committers

Commit access to the GPII repository is a responsibility. Committers agree to:

  • Remain subscribed to the gpii-committers mailing list.
  • Communicate their progress, designs, and intentions publicly to the architecture@lists.gpii.net mailing list.
  • Review and comment constructively on code in their area of expertise.
  • Vote on new committers whose work they are familiar with.
  • Respect boundaries: commit access to the GPII organization is global. Use it wisely and ask first. If you're unfamiliar with a particular area of the code, ask someone to review and commit your changes for you. Talk to maintainers and experts who know about the module you're contributing to; don't commit code to an area that someone else is working on without talking with them about it first.

Please see the Apache Foundation list of responsibilities for committers for more committer expectations.

The GPII technical process does not currently include the concept of a Project Management Committee or Conductors Group as Apache and Mozilla do. Instead, all committers are expected to participate in the work of making strategic technical decisions and ensuring a fair and open approach to communication. This helps to emphasize meritocratic governance, low bureaucratic overhead, and collective responsibility amongst committers.

Committer Emeritus

Committers sometimes become inactive for a variety of reasons. To keep the repository secure and to simplify commit access-related processes, inactive committers are given the status of Committer Emeritus. Committer emeriti no longer have access to push to the GPII's GitHub repositories and are not expected to participate in community governance issues. However, if a committer emeritus returns to the project at a later date and asks for commit access, they can be reinstated without a vote. Committer emeriti are listed on the committer's list as such.

Committers become emeriti either:

  1. When they request committer emeritus status
  2. After a year of inactivity


Revoking Commit Access

A goal of the GPII Technical Governance process is to avoid the extreme case where commit access needs to be revoked. As Karl Fogel says in his Producing Open Source Software book:

The first thing to be said about revoking commit access is: try not to be in that situation in the first place. Depending on whose access is being revoked, and why, the discussions around such an action can be very divisive. Even when not divisive, they will be a time-consuming distraction from productive work.

However, if a committer consistently behaves poorly, disregards the technical standards or inclusion policy, or causes other serious problems, commit access may be revoked. In the case of a serious problem, one or more committers with concerns will notify the private committers list with clear examples of the problem. This should not be done carelessly, based on passing irritation, or without a sense that you are not alone in your concerns. The committers will investigate and make a decision about how to proceed. Discussions will be private, but if commit access is revoked it will be announced publicly in a careful and tactful way.

Current Committers

  • Antranig Basman
  • Colin Clark
  • Cindy Qi Li
  • Javi Hernandez
  • Kasper Markus
  • Simon Bates
  • Steve Githens
  • Yura Zenevich
  • Boyan Sheytanov (Emeritus)

Core Repositories

The following repositories in the GPII GitHub organization are core repositories and are thus subject to this technical governance process:

Changes to This Policy

If changes to the GPII Technical Governance Policy are needed, this policy should govern the decision-making process. Technical governance changes require a formal vote, leaving sufficient time for all to consider and respond.