This is the charter of the W3C Web of Things Community Group. This is the official list of activities and work that this group plans to do.
Goals
The goal of WoT Community Group is to accelerate the community activities around the recommendations and notes published by the WoT WG and IG. More concretely, the group aims to:
- Increase awareness of the WoT specifications
- Collect use cases from the wider community
- Collect implementation experience and references to technologies from the wider community
- Facilitate the implementation of the specifications by providing guidelines and tutorials
Scope of Work
In order to achieve the above goals, the scope of the Web of Things Community Group includes the following activities:
- Organizing events such as hackathons, plugfests, ideathons, etc.
- Supporting other communities to host W3C WoT related events, i.e. satellite events
- Supporting communication between WoT-related developers through platforms such as Gitter, Matrix, StackOverflow, etc.
- Increasing the social media presence of the W3C WoT
- Handling questions and discussions on the standards of the Web of Things Working and Interest Groups
- Coordinate activities with the Web of Things Working and Interest Groups
In addition, the WoT CG will report the results of its activities back to the Web of Things Working and Interest Groups, the W3C membership, and the Web community.
The Web of Things Community Group, together with the Web of Things Interest Group will decide in the future how to manage the Web of Things Website together. How this collaboration will work is defined in a separate document.
Out of Scope
Publishing recommendations (standards specifications) is out of the scope of this community group (thus the CLA patent policy does not apply)
Deliverables
Specifications
No specifications will be produced under the current charter.
Non-Normative Reports
The group may produce other Community Group Reports within the scope of this charter that are not specifications, for instance use cases, requirements, implementation experience reports, or white papers.
Test Suites and Other Software
There are no plans to create a test suite.
Other Deliverables
The group may produce deliverables to promote or explain the W3C Web of Things standard. For example (but not limited to):
- Multimedia content: Videos, Podcasts, Slides, etc.
- Code snippets and examples
- Thing descriptions or Thing Models
- Tutorials (written or in other forms)
Dependencies or Liaisons
The Web of Things Community Group will manage dependencies and liaisons separately in the documents listed below:
Any changes to these documents need to be either a Pull Request reviewed by the chairs or agreed upon in a public meeting.
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.
Work Limited to Charter Scope
The group will not publish on topics other than those listed under Deliverables above. See below for how to modify the charter.
Contribution Mechanics
Substantive Contributions to Deliverables can only be made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA).
Deliverables created in the Community Group should use the W3C Software and Document License where possible.
Community Group participants agree to make all contributions in the GitHub repo the group is using for each particular deliverable. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue.
Only commits against this repository’s deliverables are considered contributions. Discussions that take place in chat platforms, social media or similar are not contributions and are exempt from the rules that apply to the deliverables. However, Code of Ethics and Professional Conduct still applies.
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, including organizational matters, in public. All technical work will occur in its GitHub repositories (and not in mailing list discussions or in chat platforms) and any work or discussion that happens elsewhere is not considered official. This is to ensure contributions can be tracked through a software tool. Announcements should be made via public emails and messages in chosen chat platform.
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) if 5 participants, no two from the same organisation, call for an election. To do so, 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). If there are not enough participants or the participants are from the same organisation, thus not meeting the above-mentioned criteria, participants should ask the Community Development Lead to intervene.
- Participants announce their candidacies. Participants have 14 days to announce their candidacies via email, 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.
- 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.
