This document is based on the original proposal. Please raise issues with feedback.
The Web Incubator Community Group (WICG) provides a lightweight venue for proposing and discussing new web platform features. Each proposal will be discussed in its own repository within the group's Github account. Membership of the group is open to everybody but all participants will have signed the W3C Community Contributor License Agreement.
As proposals gain support and become more stable and mature they will be considered for migration to a W3C Working Group where they can be put on the Recommendation track with appropriate status and Intellectual Property (IP) considerations.
Individuals, after consultation with the Chairs, may prepare an "intent to migrate" assessment, outlining use cases, as well as implementation considerations, security, privacy, accessibility, and internationalization impacts. Those requests are evaluated within the Community Group as well as the targeted W3C Working Group, if any. The role of the CG and WG Chairs and W3C team is to facilitate the migration and ensure proper continuity in the community who proposed the idea.
W3C Community Groups provide a convenient structure within which to discuss early standards proposals with a concrete contribution license. While they are relatively simple to create, there is still enough friction in the system that causes some people to start work outside W3C with no formal IP considerations.
The goal of the WICG is to balance these two considerations. It should be as low friction as possible to make new proposals where participants make their contributions with known IP commitments.
Over time, the WICG will grow into a large community of people that have signed up for their contributions to be made according to the W3C CG CLA, much like an open source project grows a list of contributors making pull requests under the project license. The agreement only has to be accepted once and then contributions to any proposal in the CG are covered.
Different organisations will have different internal policies for managing engagement in the WICG. Some will run internal processes before allowing their representatives to engage and make contributions to a particular proposal. Others allow contributions to any proposal according to standing policies. It is up to each organisation to determine how to manage this.
This approach provides the following benefits:
The Community Group will accept and discuss any proposal for a web platform feature that would be implemented in a browser or similar user agent. Any suggestions, pull requests, issues, or comments made about a proposal fall under the CLA. Editors of feature proposals must ensure that no contributions are adopted from anyone who is not a member of the Community Group.
Features or ideas that don't have applicability in a browser (or similar user agent) should be proposed to another Community Group.
The group publishes an index of the proposals worked on in GitHub. Any speculative polyfills (sometimes called "prollyfills") or test suites will be developed in Open Source using the W3C Software and Document License.
New projects or status changes are communicated to the group through the public announcement mailing list (this list will not be used for discussing proposals).
Proposal editors should publish regular status updates to the announcement mailing list (again encouraging discussion in the GitHub repo). This allows group participants to monitor progress without having to directly watch every repo.
It is anticipated that the group will collaborate with appropriate W3C Working Groups and WHATWG Workstreams in order to transition spec proposals to the Recommendation or Living Standard track. The following groups are the most likely to adopt proposals from this group:
The group operates under the Community and Business Group Process. Terms of in this charter that conflict with those of the Community and Business Group Process are void.
Like other Community Groups, the WICG is subject to the W3C Community and Business Group Process and Patent Policy, which includes requirements for organizational licensing commitments under the W3C Community Contributor License Agreement (CLA). For the purposes of the CLA, proposals within the WICG will be considered "Specifications". Note that this means they are subject to the same rules and requirements that apply to other W3C deliverables, including rules for publication, copyright, and archiving. When people request to participate without representing their organization’s legal interests, W3C will in general approve those requests for this group with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual’s first request to make a contribution to a group deliverable. The section on Contribution Mechanics describes how W3C expects to monitor these contribution requests.
Community Group participants agree to make contributions in the GitHub repo for the project that they are interested in. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue.
The Community Group mailing list must not be used for discussing details of specific projects.
Specifications created for proposals in the Community Group must use the W3C Software and Document License.
All Github repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files.
Note: this CG will not use a contrib mailing list for contributions since all contributions will be tracked via Github mechanisms (e.g. pull requests).
The Chairs are Chris Wilson, Yoav Weiss, Marcos Cáceres, and Léonie Watson.
Participants in this group choose their Chair(s) and can replace their Chair(s)at any time using whatever means they prefer. However, if 5 participants —no two from the same organization— call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777).
Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.
This Charter can be amended by the Chairs with consultation of the Community Group, if the change is agreed to by W3C's Community Development Lead (Community Development Lead is described in the CG Process).
This group will seek to make decisions when there is consensus. The editors of a spec will determine and record consensus decisions through the spec's GitHub repo issue list with assistance from the CG Chairs. Members of the group may reopen issues with new technical information.
It is the Chairs' responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer. With that said, the group favours forward motion and dissent will not be allowed to block work on a spec.
If substantial disagreement remains (e.g. the group is divided), the Committers will continue with their preference. The issue should be recorded as decided without consensus. Individuals who disagree with the Committer's choice are strongly encouraged to take ownership of their objection by taking ownership of an alternative fork. This is explicitly allowed (and preferred to blocking progress) with a goal of letting implementation experience inform which spec is ultimately chosen by the group to move ahead with.
Initially, only the Editor's are the only Committers. It is expected that participants can earn Committer status in a GitHub repo through a history of valuable contributions as is common in open source projects.
The group will conduct all of its technical work on its GitHub repositories (and not in mailing list discussions). This is to ensure contributions can be tracked and to ensure that engagement will scale to a large number of proposals.
Any decisions reached at any meeting are tentative and should be recorded in the repo issues list. Any group participant may object to a decision reached at an online or in-person meeting within 7 days of publication of the decision provided that they include clear technical reasons for their objection. The Chairs will facilitate discussion to try to resolve the objection according to the decision process.