- 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. -
-- As with other Community Groups, W3C seeks organizational licensing - commitments under the W3C Community - Contributor License Agreement (CLA) (Proposals in this Community - Group charter are applicable "Specification" in the CLA). 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, Travis Leithead, 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. -
- -