+ 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, which ran from 2014 to 2017. +
++ {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.} +
++ {TBD: Identify topics known in advance to be out of scope} +
+ ++ {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."} +
++ 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. +
++ {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. +
++ {TBD: List any significant dependencies on other groups (inside or + outside W3C) or materials. } +
++ 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 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. +
++ {TBD: if CG doesn't use GitHub replace the remaining paragraphs in this + section with: "All Contributions are made on the groups public mail list + or public contrib list"} +
++ 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. +
++ If the decision policy is documented somewhere, update this section accordingly to link to it. +
++ 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 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. +
++ 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 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. +
+ +