web-platform-dx/web-features is an open source project that depends on contributions from the community.
As long as they abide by the W3C Code of Ethics and Professional Conduct (CEPC), anyone may contribute to the project at any time by submitting code, participating in discussions, making suggestions, or any other contribution they see fit.
This document describes how various types of contributors work within the project and how decisions are made.
Everyone who is involved in any form with the project must abide by the CEPC. Everyone is expected to be respectful of fellow community members and to work collaboratively. Consequences for not adhering to the CEPC are described in the linked document.
Users are community members who have a need for the project. They are typically consumers of data, packages, or other products of the project. Anyone can be a User; common User contributions include promoting the project (e.g., display a link on a website and raise awareness through word-of-mouth), informing developers of strengths and weaknesses from a new user perspective, or providing moral support (a “thank you” goes a long way).
Users who continue to engage with the project and its community will often become more and more involved. Such Users may find themselves becoming Contributors, as described in the next section.
Contributors are community members who contribute in concrete ways to the project, most often in the form of data updates, code, and/or documentation. Anyone can become a Contributor, and contributions can take many forms. There is no expectation of commitment to the project, no specific skill requirements, and no selection process. We do expect contributors to follow the CEPC.
Contributors:
- Have read-only access to source code and therefore can submit changes via pull requests.
- Have their contribution reviewed and merged by a Peer or Owner. Owners and Peers work with Contributors to review their code and prepare it for merging.
- May also review pull requests. This can be helpful, but their approval or disapproval is not decisive for merging or not merging PRs.
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 becoming a Peer by an existing Peer or Owner.
Peers are community members who have shown that they are committed to the continued development of the project through ongoing engagement with the community. Peers are given push/write access to the project’s GitHub repository.
Peers:
- Must follow documented contribution guidelines.
- Must submit pull requests for all their changes.
- May label and close issues.
- May merge pull requests that add or modify features.
- Other contributors’ pull requests may be merged by Peers.
- A Peer's own pull requests may be merged after approval from a fellow Peer or Owner.
- Must have their status, infrastructure, and documentation work reviewed and merged by Owners.
- Such pull requests change Baseline and other statuses, schemas, project direction-setting documentation, code files, and configuration files, or any change that would result in a Semantic Versioning MAJOR release.
- Should ask for additional review from other Peers or Owners on others' PRs that are disruptive or controversial.
To become a Peer one must:
- Have shown a willingness and ability to participate in the project in a helpful and collaborative way with other participants.
- Have shown that they have an understanding of and alignment with the project, its objectives, and its strategy.
- Have contributed a significant amount of work to the project (e.g. in the form of PRs or PR reviews), thereby demonstrating their trustworthiness and commitment to the project.
New Peers can be nominated by any existing Peers or Owners. Once they have been nominated, there will be a vote by the Owners. The Owners hear nominations and vote on nominees in a private setting. A majority vote (see Decision making) confirms a nominee. If a nominee is confirmed, then the Owners group extends an invitation to join the Peers group to the nominee If the nominee accepts the invitation, then the Owners group adds the Peer’s name to the List of current Peers.
It is important to recognize that being a Peer is a privilege, not a right. That privilege must be earned and once earned it can be removed by the Owners. However, under normal circumstances the Peer status exists for as long as the Peer wishes to continue engaging with the project. Inactive Peers (no activity on the project for months or more) might be marked as inactive or removed by the Owners and may re-enter when they choose to contribute again.
- Adriana Jara (@tropicadri)
- Brian Kardell (@bkardell)
- Dietrich Ayala (@autonome)
- James Stuckey Weber (@jamesnw)
- Mariko Kosaka (@kosamari)
- Patrick Brosset (@captainbrosset)
- Pete LePage (@petele)
A Peer who shows an above-average level of contribution to the project, particularly with respect to its strategic direction and long-term health, may be nominated to become an Owner, described below.
The project is governed by the Owners group in consultation with the Peers group and the WebDX Community Group. Owners are collectively responsible for high-level guidance of the project.
The Owners group has final authority over:
- Adoption or amendment to the definition of Baseline
- Adoption or amendment to the definition of other feature availability statuses
- Resolving disagreements on the scope or status of individual features
- Technical direction of the project, especially infrastructure and schema decisions
- Project governance and process (including this policy and any updates)
- Confirming Peers and Owners
- Contribution policy
- GitHub repository hosting
Being an Owner is not time-limited. There is no fixed size of the Owner group. The Owner group should be of such a size as to ensure adequate coverage of important areas of expertise balanced with the ability to make decisions efficiently. An Owner may be removed from the Owner group by voluntary resignation, or by a standard Owner group motion, including for violations of the CEPC or other contribution requirements as described in the project’s contribution documentation.
Changes to the Owner group should be posted in the agenda, and may be suggested as any other agenda item (see Project meetings).
Owners fulfill all requirements of Peers, and also:
- Must ensure the smooth running of the project.
- Should review code contributions, changes to this document, or changes to the licensing of the project or its outputs.
- May merge pull requests that remove features.
- May merge pull requests that change the Baseline definition or its implementation.
- May merge pull requests that change Baseline statuses.
- May merge pull requests that change other availability statuses.
- May merge pull requests that change project documentation or infrastructure.
- May merge pull requests that result in a Semantic Versioning MAJOR release.
- Should release package(s) on a regular basis (or review and approve automation with the same effect).
To become an Owner one must fulfill at least the following conditions and commit to being a part of the community for the long-term:
- Have worked in a helpful and collaborative way with the WebDX community.
- Have given good feedback on others’ submissions and displayed an overall understanding of the code quality standards for the project.
- Have the ability to drive the project forward, manage requirements from users, and take on responsibility for the overall health of the project.
See also: Additional paths to becoming a Peer or Owner
New Owners can be nominated by existing Owners. Once they have been nominated, there will be a vote by the Owners. The Owners hear nominations and vote on nominees in a private setting. A majority vote (see Decision making) confirms a nominee. If a nominee is confirmed, then the Owners group extends an invitation to join the Owners group to the nominee. If the nominee accepts the invitation, then the Owners group adds the new Owner’s name to the List of current Owners.
- Alexis Deveria (@Fyrd)
- Dan Fabulich (@dfabulich)
- Daniel D. Beck (@ddbeck)
- Florian Scholz (@Elchi3)
- James Graham (@jgraham)
- Kadir Topal (@atopal)
- Leo McArdle (@LeoMcA)
- Philip Jägenstedt (@foolip)
The Owners group may, at their discretion, invite domain experts or key consumers of the project to become Peers or Owners. For example, a representative from a browser vendor may be invited to give their input on Baseline statuses or a representative from Can I use…? may be invited to give their input on how project decisions might impact readers of Can I use…?. Such Peers and Owners are indicated in the Peers or Owners list with the text “invited representative for” followed by the name of the applicable organization or interest group.
Owners may, at their discretion, nominate an owner-delegate to carry out a task or make a decision ordinarily carried out by an Owner or Peer. Delegation should be limited in duration or scope, or both; delegation may be withdrawn by any Owner at any time. For example, an Owner may nominate a tool expert as an owner-delegate to approve an infrastructure PR or nominate a feature expert as an owner-delegate to approve a feature.
Decision making follows a consensus-seeking decision-making model, which encourages participants to exhaust attempts to achieve true consensus before falling back to a vote. Votes, if required, take place at project meetings.
When an agenda item has appeared to reach a consensus, the chair will ask “Does anyone object?” as a final call for dissent from the consensus.
If an agenda item cannot reach a consensus, an Owner can call for either a closing vote or a vote to defer the issue to the next meeting. The call for a vote must be approved by a majority of the Owners or else the discussion will continue. Simple majority wins.
Whether by consensus or vote, whenever the Owners make a collective decision, they commit to memorializing that decision in writing (e.g., through the creation or modification of a document, a comment on a pull request, issue, or discussion, or through some other durable record).
The Owners commit to meeting on a quarterly basis, or more often as needed, on a schedule and duration to be determined by the Owners group.
The meeting is run by a designated chair selected by the Owners group. Meetings will typically tend to important or unresolved matters, such as modifications of governance, contribution policy, project membership, or release process.
Reviewing and renewing the definition of Baseline must appear on the agenda of the Owners group meeting at least once per calendar year.
Any community member or Peer can ask that something be added to the next meeting’s agenda by logging a GitHub Issue. Peers can add the item to the agenda by adding the meeting-agenda label to the issue and Contributors can ask Peers or Owners to add the label for them (though they’re not obliged to accept the request).
The intention of the agenda is not to approve or review all patches. That should happen continuously on GitHub and be handled by the larger group of Peers. The exception to this is when a PR discussion has stalled due to disagreement or inaction, and progress needs to be unblocked.
Before each project meeting, the chair will share the agenda with the Owners and Peers. Owners can add any items they like to the agenda at or before the beginning of each meeting. The chair (or other Owners) cannot veto or remove items, except by unanimous consent of the Owners. Agenda items not addressed by the end of the meeting are automatically deferred to the next meeting.
The Owners may invite Peers or other guests to participate in a non-voting capacity.
The chair is responsible for summarizing the discussion of each agenda item and adding it to the repository after the meeting.
| Privilege / responsibility | Everyone / Users | Contributors | Peers | Owners |
|---|---|---|---|---|
| Abide by the CEPC | Yes | Yes | Yes | Yes |
| Promoting the project | Yes | Yes | Yes | Yes |
| Make use of the data, fork it, repackage it, etc. | Yes | Yes | Yes | Yes |
| Open pull requests or issues | Yes | Yes | Yes | |
| Review pull requests or comment on issues | Yes | Yes | Yes | |
| Label issues and PRs | Yes | Yes | ||
| Merge a new or modified feature | Yes | Yes | ||
| Merge changes to a feature’s status | Yes | Yes | ||
| Merge removal of a feature | Yes | |||
| Merge policy changes | Yes | |||
| Merge schema or infrastructure changes | Yes | |||
| Release new npm package versions | Yes | |||
| Adopt or modify the Baseline definition | Yes | |||
| Adopt or modify other status definitions | Yes | |||
| Merge to branches directly (without pull requests) | Yes |
This work is a derivative of mdn/browser-compat-data Governance, ESLint Governance, YUI Contributor Model, and the JS Foundation TAC Charter.