Community Group Charter

This document has been reviewed by community group members and, where applicable, adopted the Community Group Charter template provided by W3C. It provides important governance information relevant to this community group.

Mission

This group will create guidelines, tools, and resources for web and digital professionals to incorporate sustainability and related principles into their workflows and work practices. Our goal is to make the process of creating and managing the entire life cycle of digital products and services more sustainable, while the use of digital products should also encourage better practices for users.

We ground all our work in the three pillars of sustainability:

1. Environmental: We prioritize the health of ecosystems and the planet overall.
2. Social: Similarly, people should have access to resources, information, and opportunities necessary for their well-being.
3. Economic: Financial stability and equitable economic development—in this case, through the digital economy—ensures shared prosperity for the planet and its inhabitants.

Scope

The group will provide evidence-based, peer-reviewed recommendations on how to create more sustainable digital products and services as defined above.

Success criteria includes:

• The guidelines are used by digital professionals across sectors to create more sustainable digital products and services.
• The guidelines are adopted by schools, bootcamps, universities, and other educational institutions as best-in-class. 
• The guidelines are also included in future legislation and procurement requirements for organizations commissioning digital projects.

Out of Scope

This group will not create Specifications.

Duration

Sustainability is an ongoing and evolving concern. New topics emerge regularly. As such, this group should remain relevant for as long as the issues it addresses are. To accomplish this, we envision an organizational structure that encourages collaboration and ongoing participation and supports leadership transitions as needed.

Deliverables

Understanding that this work is intersectional:

• The group will offer guidelines for common digital sustainability practices in creating, managing, measuring, maintaining, and retiring digital products and services. 
• Where applicable, it will also suggest business and project management resources to guide organizations on broader sustainability principles.
• Similarly, the group also acknowledges that non-browser based variables are sometimes relevant to our work and should be addressed on a case-by-case basis. Examples include: green web hosting, renewable energy pricing and availability, OS-specific issues, government policies, and so on. 
• Whenever possible, the group will recommend indicators to measure success based on their ability to yield consistent results and create broad impact.   
• Finally, the team will also seek to build alliances between other initiatives that work to build a better web. For example, a more sustainable web should also be more accessible for everyone while also respecting user privacy and data ownership. 

Deliverables

Non-Normative Reports

The group may produce other Community Group Reports within the scope of this charter but that are not Specifications, for instance use cases, requirements, or white papers.

Milestones

Milestones for this work will be based on evidence-driven research and defined as the group grows and evolves.

Committees

This group has several committees dedicated to specific subtopics of the parent topic:

• UX Design
• Business Strategy, Product management
• Analytics, Measurement, Reporting
• Hosting, Infrastructure, Systems
• Web Development

Committees will review and approve individual suggested lists and resources first before submitting them for a broader group vote to be included in our overall recommended guidelines. If you would like to join a committee or create a new one, please reach out to propose a topic.

Dependencies

Generally, we will suggest a list of guiding principles similar to WCAG’s principles (perceivable, operable, understandable, robust), along with specific suggestions for each individual discipline. This feeds into a master list of guidelines. 

The group will take advantage of existing resources and compiled lists to create our recommendations. We also look forward to collaborating with other W3C groups working on intersectional topics.

Confidentiality

This work will be created publicly and transparently using open source principles. We will also abide by W3C’s level of confidentiality guidelines.

Meetings & Cadence

Individual committees will meet as often as is necessary to move their suggested guidelines forward under the timeline suggested by the main group. The main group will meet at least once per quarter to discuss progress.

Communications

• We will share updates in this community group.
• More formal proposals, records, and resources will be housed in this group’s GitHub repository.
• Ongoing discussions will take place in the #sustainability channel of the W3C Slack Workspace.

Voting Procedures

Committees will vote on issues relevant to their topics, then present the outcomes to the main group. If needed, the main group can also vote on them.

Time Commitments

This community group is comprised of busy, working professionals. Committees will meet at the cadence and velocity that works best for each group, taking into consideration the time needed to prepare and review materials before and after each meeting. The main group will meet at least once quarterly for no less than an hour.

Intellectual Property

This group adheres to open source practices. Under the W3C banner, we will follow its policies and legal guidelines. However, we will pursue the most open and freely available licensing for anything the group produces. 

Community and Business Group Process

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.

Contribution Mechanics

Substantive Contributions to Specifications can only be made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA).

Community Group participants agree to make all contributions in the GitHub repo the group is using for the particular document. 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.

Transparency

The group will conduct all of its technical work in public. If the group uses GitHub, all technical work will occur in its GitHub repositories (and not in mailing list discussions). 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, or to a GitHub issue if the group uses GitHub.

Decision Process

This group will seek to make decisions where there is consensus. Groups are free to decide how to make decisions (e.g. Participants who have earned Committer status for a history of useful contributions assess consensus, or the Chair assesses consensus, or where consensus isn’t clear there is a Call for Consensus [CfC] to allow multi-day online feedback for a proposed course of action). It is expected that participants can earn Committer status through a history of valuable contributions as is common in open source projects. After discussion and due consideration of different opinions, a decision should be publicly recorded (where GitHub is used as the resolution of an Issue).

If substantial disagreement remains (e.g. the group is divided) and the group needs to decide an Issue in order to continue to make progress, the Committers will choose an alternative that had substantial support (with a vote of Committers if necessary). Individuals who disagree with the 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.

Any decisions reached at any meeting are tentative and should be recorded in a GitHub Issue for groups that use GitHub and otherwise on the group’s public mail 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.

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.

Chair Selection

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).

1. Participants announce their candidacies. Participants have 14 days to announce their candidacies, but this period ends as soon as all participants have announced their intentions. If there is only one candidate, that person becomes the Chair. If there are two or more candidates, there is a vote. Otherwise, nothing changes.
2. Participants vote. Participants have 21 days to vote for a single candidate, but this period ends as soon as all participants have voted. The individual who receives the most votes, no two from the same organisation, is elected chair. In case of a tie, RFC2777 is used to break the tie. An elected Chair may appoint co-Chairs.

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.

Amendments to this Charter

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.