| + Charter Status + | ++ See the group status page and detailed change history. + | +||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
Start date
@@ -195,7 +203,7 @@ Updated document status is available on the group publication status page. -Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state. +Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to reach a stable state. The Working Group intends to publish the latest state of their work as Candidate Recommendation (with Snapshots) and does not intend to advance their documents to Recommendation.
@@ -212,7 +220,7 @@ Exclusion Draft: WebGPU 18 May 2021;
Expected completion: Q4 2024 +Expected completion: Q2 2025 Exclusion Draft: WebGPU Shading Language 18 May 2021;
Expected completion: Q4 2024 +Expected completion: Q2 2025 Other Deliverables- This Working Group will produce conformance test suites and + This Working Group will produce conformance test suites and implementation reports for its normative deliverables. @@ -254,18 +262,19 @@
Success Criteria-In order to advance to Proposed Recommendation, each normative specification is expected to have at least two independent implementations of each feature defined in the specification. +There should be testing plans for each specification, starting from the earliest drafts. Normative specification changes are generally expected to have a corresponding set of tests, either in the form of new tests or modifications to existing tests, or must include the rationale for why test updates are not required for the proposed update. Each specification should contain sections detailing all known security and privacy —including fingerprinting— implications, and suggested mitigation strategies for implementers, web authors, and end users. The group should not publish a specification if acceptable mitigation strategies cannot be found. Each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximising accessibility in implementations. -Normative specification changes are generally expected to have a corresponding set of tests, either in the form of new tests or modifications to existing tests, or must include the rationale for why test updates are not required for the proposed update. +This Working Group expects to follow the TAG Web Platform Design Principles. +All new features should have expressions of interest from at least two potential implementors before being incorporated in the specification. Coordination-For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a specification following a review. +For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a specification following a review. -Additional technical coordination with the following Groups will be made, per the W3C Process Document: +Additional technical coordination with the following Groups will be made, per the W3C Process Document: W3C Groups@@ -275,13 +284,13 @@W3C GroupsThe group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.- The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy. + The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy. Participants in the group are required - (by the W3C Process) + (by the W3C Process) to follow the W3C - Code of Ethics and Professional Conduct. + Code of Conduct. As stated above, the majority of the technical work for this Working Group will take place in the GPU for the Web Community Group. @@ -332,7 +341,7 @@ Communication- Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed on public repositories and may permit direct public contribution requests. The meetings themselves are not open to public participation, however. + Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed on public repositories and may permit direct public contribution requests. The meetings themselves are not open to public participation, however. Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the GPU for the Web Working Group home page. @@ -355,7 +364,7 @@ Decision Policy- This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required. + This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections. @@ -367,10 +376,10 @@If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.- All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs or the Director. + All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs. - This charter is written in accordance with the W3C Process Document (Section 3.4, Votes), and includes no voting procedures beyond what the Process Document requires. + This charter is written in accordance with the W3C Process Document (Section 3.4, Votes), and includes no voting procedures beyond what the Process Document requires. @@ -381,16 +390,15 @@Patent Policy- This Working Group operates under the W3C Patent - Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis. + This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis. - For more information about disclosure obligations for this group, please see the licensing information. + For more information about disclosure obligations for this group, please see the licensing information. Licensing-This Working Group will use the W3C Software and Document license for all its deliverables. +This Working Group will use the W3C Software and Document license for all its deliverables. About this Charter- This charter has been created according to section 3.4 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence. + This charter has been created according to section 3.4 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence. Charter History-The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3): +The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3):
François Daoust -- Copyright © - 2022 - W3C® - ( - MIT, - ERCIM, - Keio, - Beihang - ), All Rights Reserved. - - W3C liability, trademark and document use rules apply. - +Copyright © 2024 World Wide Web Consortium. |