A group to gather and incubate new features and requirements for SVG — making it easier for software developers and content creators in the SVG community to engage with the SVG standardization process.
This group will complement the SVG working group, and covers the same scope of technologies. Draft proposals for new SVG features, developed in the community group, may transition to recommendation-track specifications in the working group.
The community group will support the standardization and adoption of Scalable Vector Graphics (SVG) through three types of work:
SVG is a set of interelated technologies used to create vector graphics. The scope of SVG for the community group is as defined in the SVG working group charter, including its markup syntax, styling characteristics, rendering model, and object model.
Incubate, in the context of a proposed specification, means to:
After successful incubation, a proposed specification would be ready for transition to the W3C technical report process (AKA, the “recommendation track”).
See Deliverables for examples of in-scope work.
Any normative specification being actively developed by the SVG working group, or other recommendation-track group, is out of scope for the community group.
A feature proposal is not in scope for community group if that feature has multiple independent, non-experimental implementations shipping in consumer-oriented software (that is, not including preview or “Nightly” versions of the software, or implementations requiring special opt-in to the feature). If new implementations make a feature become out-of-scope, any proposed specification for that feature should be transitioned to a recommendation-track process as soon as possible.
However, inactive proposals from the working group are in scope for incubation in the community group. For example:
Because the community group is designed to provide a forum to discuss new proposals for SVG, this charter cannot exhaustively list all possible specifications which could be incubated. However, the following draft specifications and features have previously been developed by the SVG working group, but are not currently in its charter scope, and are therefore available for incubation in the community group:
childsyntax for defining references to graphical elements.
z-indexfor SVG rendering
There are no specific timelines for any of these projects, as of the date this charter was drafted.
The group may produce other Community Group Reports, that are within the scope of this charter but that are not Specifications, for instance use cases, requirements, white papers, or best-practices guides.
In particular, the draft SVG Authoring Guide could be completed under the scope of the community group. Separate best practice guides could provide guidance for SVG authoring tools and other software that exports or manipulates SVG files. Use-case and requirements reports could review how SVG and other vector graphics languages are being used, separate from any specification proposal.
Participants developing draft specifications in the community group should include matching test suites. For organizational purposes, the test suite is considered part of the same project as the proposed specification.
The group may host other open-source software projects that support SVG standardization, including:
This community group is tightly affilliated with the SVG Working Group. Its work may intersect with the work of any of the other groups mentioned in the “Coordination” section of the SVG working group's charter.
In particular, many projects will need to be coordinated with the CSS Working Group. All projects will need to consider guidelines produced by the W3C's horizontal review groups:
The group operates under the Community and Business Group Process. Terms 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). 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.
The W3C Code of Ethics and Professional Conduct applies to participation in this group.
The group will not publish Specifications on topics outside the scope defined in Scope of Work above. See below for how to modify the charter.
Technical work of the community group will be divided into individual projects, where a project may be one of the following types of deliverables:
Each active group project — meaning, a project where work is ongoing and contributions are accepted — must have clearly identified project lead(s) who are responsible for that project's process and deliverables. If the project is a proposed specification, the project leads include the specification editors. If at any time an active project no longer has a lead, then the community group chair(s) take over that role until a new project lead can be identified.
Project leads may maintain lists of project team members or contributors who may participate in the project decision process, so long as the process of identifying team members is documented, fair, and consistent with the Community and Business Group Process. In the absence of an explicit project team list, the project team consists of any community group members who choose to participate in the project's discussions.
The community group chair(s) will work to coordinate communication, support project leads, resolve disputes within project teams, and to liase with the SVG working group, other working groups, and W3C management. The chairs may delegate any of these tasks to other group members.
Substantive Contributions to Specifications can only be made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA).
Specifications created in the Community Group must use the W3C Software and Document License. All other documents produced by the group should use that License where possible.
All test suite contributions must be released under the W3C 3-clause BSD License, so they can be readily integrated in the Web Platform Tests project if and when a specification is adopted.
All other software projects hosted by the group must include an open-source licence compatible with the W3C Software and Document Notice and License.
Community Group participants agree to make all contributions in the GitHub repo the group is using for the particular project. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue.
All Github repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files (or a suitable alternative licence file, if the W3C Software and Document License file isn't being used).
Each project hosted by the community group will have a dedicated GitHub repository, which must be used to track contributions and technical discussion and decisions.
The community group website and mailing list should be used primarily for administrative matters, announcements, introductions, procedural guidance, and other non-technical discussion.
The group's IRC channel (#svgcg) may be used by group members for informal real-time collaboration, provided that all technical contributions and decisions are recorded in the relevant GitHub commits or issue tracker.
Other methods of communication (for example, social media accounts) may be used by the chair(s) or their delegates to increase awareness of the community group's activities.
The community group may hold annual face-to-face meetings as part of W3C's TPAC. In addition, project teams may choose to arrange meetings (teleconference, videoconference, or face-to-face) as needed, so long as they meet the requirements of the Community Group Meeting Policies regarding advance notice and published minutes. An internal mailing list is available to coordinate meeting logistics (but notice and agendas must be made on a public forum).
Any decisions reached at any meeting are tentative and should be recorded in a GitHub Issue (for technical matters) or otherwise on the group's public mail list (for administrative and procedural matters not associated with a particular repository). 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.
Any group members may propose a new project. The chair(s) will maintain a forum for discussing project proposals and seeking collaborators.
The chair(s) or other group members delegated by the chair(s) must create a new project repository in response to a request in this forum, if the following conditions are met:
The initial project leads are the people who made the project request, or as otherwise identified in the discussion for the proposal. Thereafter, project teams may select new leads by consensus or through the decision process.
Project leads must ensure that:
The chair(s) may appoint new project leads at any time if the current project leads fail to fulfill these obligations.
Any project may become inactive if the project team or leads decide that it has completed its work, or that further work is no longer desired. The project lead(s) or chair(s) must ensure that Inactive projects are clearly identified as such in the project repository, and must not accept new contributions other than errata.
Project leads may request at any time to publish a document for the project as a draft report of the community group. If the document meets the requirements for Community Group Deliverables, the chair(s) must request a community-group decision on whether to adopt the draft.
When project leads believe that a specification proposal project has completed incubation, they should prepare an intent to migrate request (published within the project repository). After receiving notification of the request, the chair(s) must request a community-group decision on whether to adopt the proposal as a final report. In addition, the chair(s) should work with the project leads to transition the proposed specification to the SVG working group or other standards group.
The chair(s) should ensure that new projects, project reports, and changes to project status (completed or inactive) are announced to the all community group members.
The group will conduct all of its technical work in public. All technical work will occur in, or be recorded in, its GitHub repositories. This is to ensure contributions can be tracked through a software tool.
Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to the group's public mailing list (for administrative discussion), or to a GitHub issue (for technical discussion).
This group — as a whole and for individual projects — will seek to make decisions where there is consensus. The following process is to be used to make decisions in any of these situations:
A decision process should be managed either by a project lead (for a project technical decision), or by a chair (for any decision).
The decision process, and any formal objections or other requests for a decision, must be carried out in writing in the following locations:
For a project technical decision, the decision process participants are project team members. For an administrative or procedural decision, including any debate on who should qualify as a project team member, the decision process participants are any community group member as of the time the decision process is initiated.
The chair or project lead managing the decision process should start by publishing a proposed resolution with a Call for Consensus (CfC). Alternatively, if there is no clear proposed resolution, the chair or project lead may issue a Call for Proposals (CfP), asking for suggested courses of action to resolve the issue.
The Call for Consensus or Call for Proposals must include an explicit end date, at least 7 days from publication of the call. During that period, decision process participants may respond with an objection (to a CfC) and an alternative proposal.
If no objections to a proposed resolution are received by the end date of the CfC, or if only one proposed resolution is received for a CfP, then that proposal is accepted as a decision.
If, however, the CfC/CfP period ends with more than one proposed action, the chair or project lead managing the decision process must call for a vote. A vote may use an online poll/form, or may be conducted by written replies, so long as vote participants are identifiable. The call for a vote must include a new end date (at least another 7 days in the future). Decision process participants should then respond to indicate their preferred course of action (possibly ranked, if there are many alternatives). At the end of the voting period, the chair or project lead managing the decision process must select an alternative with substantial support and publish it in the same forum as the original call for a decision.
If any group members still disagree with a decision about a project, they may request to start a new project that is a fork of the original one. 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.
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.
Participants in this group choose their Chair(s) and can replace their Chair(s) by consensus or by following the decision process.
However, if 5 participants, no two from the same organisation, 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.
The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.