This Charter is work in progress. To submit feedback, please use https://github.com/swicg/potential-charters/issues Issues where Charter is being developed.
The Social Web Incubator Community Group (also known as SocialCG, or SWICG) is the successor of the [Social Web Working Group](https://www.w3.org/wiki/Socialwg), which ran from 2014 to 2018.
The group will maintain errata and corrected drafts, consisting of the published document with errata applied, for the following recommendations from the Social Web Working Group:
It will maintain errata and corrected drafts, consisting of the published document with errata applied, for the following Notes from the Social Web Working Group:
The group will maintain the Activity Streams 2.0 JSON-LD context document and add new extension terms as they become widely implemented.
The group will maintain the Activity Streams 2.0 OWL ontology.
The group will develop extensions to ActivityPub and Activity Streams 2.0, and other specifications as needed, to address new use cases and requirements.
The group will develop and document integration between ActivityPub and other protocols, such as Webfinger, HTML, and HTTP Signature.
The group will develop and support the development of test suites and reference implementations for the above specifications and extensions.
The group will provide an interface and touchpoint for other W3C groups and external organizations working with these specifications.
The group will provide information for implementers of these specifications, including best practices, tutorials, and examples.
{TBD: Identify topics known in advance to be out of scope}
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.
The group MAY produce test suites to support the Specifications. Please see the GitHub LICENSE file for test suite contribution licensing information.
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 Conduct applies to participation in this group.
The group will not publish Specifications on topics other than those listed under Specifications above. See below for how to modify the charter.
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.
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.
The group will conduct all of its technical work in public, e.g. on the public-swicg@w3.org mailing list, w3.org SocialCG wiki, and git repositories cloned in the github.com/swicg/ Organization .
Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to the public-swicg@w3.org mailing list.
This group will seek to make decisions where there is consensus. The Group makes decisions in the following ways: either Committers assess consensus, or the Chair assesses consensus, or where consensus isn't clear there is a Call for Consensus [CfC] (see below) to allow multi-day online feedback for a proposed course of action. 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.
To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions via email to public-swicg@w3.org, preferably with the abbreviation CfC early in the subject line to catch more attention.
Any group participant may object to a decision reached at an online or in-person meeting within 14 days of publication of the decision, provided that they include clear reasons for their objection grounded in the scope and documented goals of the CG and its work items.
The presence of formal resolutions will be indicated by a "CfC" prefix in the subject line of an email on the list. Additional outreach to community venues for more affirmative consent is strongly encouraged. There will be a response period of 14 days. If no sustained objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Community Group, i.e. a group decision. 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.
The Chairs will facilitate discussion to try to resolve the objection according to this 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.
The role of the Chair is described in the Art of Consensus.
The Community Group participants elect (and/or other chairs appoint) no fewer than One (1) and no more than Three (3) Chairs for the group at any given time. The W3C Team Contact of the group SHOULD NOT be one of the chairs at any point. Participation as Chair is afforded to the specific individuals elected to those positions, and a participant"s seat MUST NOT be delegated to any other person.
For most Chair nominees, the primary affiliation is their employer and will match their affiliation in the W3C database. For contractors and independents, this will normally be their contracting company or their independent status; in some cases (e.g. where a consultant is consulting for only one organization) this may be the organization for whom the nominee is consulting. Chair nominees, elected chairs, and appointed chairs MUST have unique affiliations publicly stated at time of nomination, election (if it has changed since last disclosure), or appointment. Publicly stating additional or secondary affiliations is not required but recommended. An organization with which one or more participants are affiliated MAY submit one ballot that ranks candidates in their preferred order as an organization as an informational exhibit; individual participants should still vote explicitly, whether concurring or dissenting with such an exhibit.
Task Forces are lightweight organizational subsets of the Community Group that serve to channel work and attention to tasks (and allow others to "tune out" of the many topics and work items proceeding in parallel that are less pressing for them). They can schedule their own topic calls (i.e. public, minuted meetings on the CG calendar) and can tag niche email threads with the name of their task force as a courtesy to the rest of the group. When minutes from task-force specific topic calls are uploaded, they are marked by task force name. "Task Forces" are spun up by community group resolution, usually to work on a work item at any stage of formalization or to accomplish some other objective, and can be spun down or change scope at any time by internal consensus. The convener of a task force does NOT need to be the "champion" of a work item being coordinated in it, NOR do they need to be a Committer.
A Committer is authorized to make changes to one or more GitHub repositories that are managed by the group. Participants can earn Committer status through a history of useful contributions. Committer status is granted through consensus, as discussed in Decision Process. There is no limit to the number of Committers in the group or on a repository. There is no time limit on Committer status. Each repository for ongoing work items should have at least one active Committer other than the Chairs. Chair(s) can revoke Committer status for any reason, and will notify the community. A Committer can give up the role voluntarily.
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.