[DRAFT] Social Web Incubator Community Group Charter

This Charter is work in progress. To submit feedback, please use https://github.com/swicg/potential-charters/issues Issues where Charter is being developed.

• This Charter: {TBD: URI}
• Previous Charter: {TBD: URI}
• Start Date: {TBD: date the charter takes effect, estimate if not known. Update this if the charter is revised and include a link to the previous version of the charter.}
• Last Modifed: 2024-09-26

The Social Web Incubator Community Group (also known as SocialCG, or SWICG) is the successor of the Social Web Working Group, which ran from 2014 to 2017.

Goals

• Provide space to collaborate and coordinate for implementors who are building on any of the specifications published by the Social Web WG (2014-2017), and related technologies.
• Incubate new proposals which build on or complement the Social Web WG recommendations.

Scope of Work

{TBD: Describe topics that are in scope. For specifications that the CLA patent section applies to, it is helpful to describe the scope in a way that it is clear what types of technologies will be defined in specifications, as opposed to adoption by reference or underlying technology not defined in the proposed spec. Key use cases are often helpful in describing scope. If no specifications will be defined in the group that the CLA patent section applies to, the charter should clearly state that. A clear scope is particularly important where patent licensing obligations may apply.}

Out of Scope

{TBD: Identify topics known in advance to be out of scope}

Deliverables

Specifications

{TBD: Provide a brief description of each specification the group plans to produce. Where an estimate is possible, it can be useful to provide an estimated schedule for key deliverables. As described below, the group may later modify the charter deliverables. if no specifications, include: "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 but that are not Specifications, for instance use cases, requirements, or white papers.

Test Suites and Other Software

{TBD: If there are no plans to create a test suite or other software, please state that and remove the following paragraph. If Github is not being used, then indicate where the license information is. If GitHub is being used link to your LICENSE.md file in the next paragraph.}

The group MAY produce test suites to support the Specifications. Please see the GitHub LICENSE file for test suite contribution licensing information.

Dependencies or Liaisons

{TBD: List any significant dependencies on other groups (inside or outside W3C) or materials. }

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 Conduct applies to participation in this group.

Work Limited to Charter Scope

The group will not publish Specifications on topics other than those listed under Specifications above. See below for how to modify the charter.

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

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.

Transparency

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.

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] (see below) 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 discursive 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.

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.

Calls for Consensus

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.

Chairs

The role of the Chair is described in the Art of Consensus.

The Community Group participants elect (and/or other chairs appoint) no less 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.

Chair Selection

• At any given time there may be up to three co-chairs, each holding one seat. Each seat defines a 2 year cycle of service.
• In the first election after ratification of this charter, all seats will be up for election. Thereafter, in each year, a single election will be held to fill any vacant seats.
• In the case of interim vacancy, the remaining chairs may appoint a co-chair for each open seat, hold an election for the same, or wait until the next election, at their discretion. If the chairs do not take any action, the seat will automatically be up for election in the next cycle. Any such interim appointments or elections shall hold the seat until the end of its natural cycle.
• Reelection is restricted to two consecutive terms, with the possibility of being reelected after sitting out one election cycle.
• In an election year, current chairs will select a date for elections, which will set a nomination period of two weeks, starting 4 weeks prior to the election.
• For an individual to run for election, they must self-nominate and make a statement regarding their background and why they are running, on the group mailing list.
• The current chairs will host a conference call during the nomination period, during which candidates may make a statement and answer questions from the community.
• If, at the end of nominations, any given seat only has a single candidate, that candidate immediately wins that seat. For any seats with multiple nominees, there will be an election for those seats.
• If, after nominations, any given seat has no candidates, the remaining chairs after any election (if necessary for other seats), will address the vacancy as an interim vacancy, described above.
• To elect one of multiple candidates, a vote will be held by the election mechanism of ranked choice voting, in which voters rank candidates by preference on their ballots. The candidate with the majority (more than 50%) of first-choice votes wins outright. If no candidate gets a majority of first-choice votes, the candidate who ranked the worst is eliminated, and that candidate"s voters" ballots are redistributed to their second-choice pick. If the vote results in a tie, an immediate runoff of the top two candidates shall be held. If the vote remains tied, the winner shall be the candidate whose nomination was first recorded publicly on the group email list.

Chair Offboarding

• A chair may voluntarily off-board at any given time; this should be done publicly and on the mailing list.
• Chairs may also be removed from their duties through a no-confidence vote.
• If a participant of the community group wishes to call for the recall of a chair, for any reason, that participant must first privately communicate with one or more of the other chairs their desire and reason for doing so. Those chairs must give the participant an opportunity to discuss their concerns with a goal of resolving them. If, after 30 days, the participant feels their issues have not been adequately addressed, they may then escalate to a public call for a no-confidence vote (without having to disclose with whom they have been discussing the matter). If, after 60 days, the participant has not made a call for a no-confidence vote, the matter should be considered dropped; any further attempts to remove the chair in question must begin with a new round of private communication.
• A public call for no-confidence must be announced to the group email list stating the name of the chair subject to the recall. This announcement must come from the participant who initiated the private communication with the chairs to discuss their concerns. At least two other supporting participants MUST reply to that email on the public list within 48 hours to confirm their support for a no-confidence vote of the chair in question.
• The other chairs must acknowledge the call for no-confidence within 7 days of all three participants declaring their support.
• UNLESS the chair in which no-confidence has been expressed voluntarily offboards and opts out of the session on the mailing list, and within 30 days of a call for no-confidence, the other chairs MUST hold a conference call at which the parties seeking no-confidence will have an opportunity to present their case and participants of the group will be able to ask clarifying questions. The chair in question SHALL NOT moderate this call. They will, however, have equal time to respond during that same call to the case made against them.
• During the week following this conference call, participants may cast votes in favor or against the recall by posting to the email list.
• If affirmative votes cast that week (in favor of recall) comprise greater than two-thirds of the total votes cast, then the chair in question is removed and the seat shall be treated as an interim vacancy.
• Participants are not required to vote. Abstentions may be recorded; such abstentions shall not count towards the total number of votes when calculating the two-thirds majority.
• A Chair who has been removed may stand for reelection.
• Only one call for no-confidence, for one chair, may be in process at any given time. Priority shall be given to the first such vote to be publicly called. Any subsequent public calls must wait until any previous recalls are resolved, then must start with private communication as described above.

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.