DRAFT Social Web Maintenance Working Group Charter
+ + + +The mission of the + Social Web Maintenance Working Group + is to maintain the W3C Recommendations, as well as related Notes, in the + area of Social Web. +
+ + + + + +This proposed charter is available + on GitHub. + + Feel free to raise issues. +
+ +| + Charter Status + | ++ See the group status page and + detailed change history. + | +
|---|---|
| + Start date + | ++ [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved) + | +
| + End date + | ++ [dd monthname yyyy] (Start date + 2 years) + | +
| + Chairs + | ++ [chair name] (affiliation) + | +
| + Team Contacts + | ++ [team contact name] + (0.1 FTE) + | +
| + Meeting Schedule + | +
+ Teleconferences: topic-specific calls may be held
+ or something else
+ + Face-to-face: we will meet during the W3C's annual Technical Plenary week; + additional face-to-face meetings may be scheduled by consent of the participants, usually + no more than 3 per year. + |
+
Motivation and Background
++ In the past few years, the Social Web Community Group acted as a + maintainer for Social Web related specifications published by W3C. + This Working Group would maintain the Recommendations and Notes in the + Social Web area. +
+Scope
+ +
+ The Working Group will maintain the
+ ActivityPub,
+ WebSub,
+ Activity Streams,
+ Activity Vocabulary,
+ MicroPub,
+ Linked Data Notifications, and
+ Webmention
+ specifications, as well as related Notes.
+
+
+ Changes that add new functionality (class 4) are out of scope.
+ Out of Scope
+
+ Deliverables +
+ +Updated document status is available on the + group publication status page. +
+ ++ Normative Specifications +
++ The Working Group will deliver the following W3C normative specifications: +
+-
+
- ActivityPub +
-
+
Adopted Draft: @@to be filled later@@ +
Exclusion Draft: @@to be filled later@@ + Associated @@to be filled later@@ +
Exclusion Draft Charter: @@to be filled later@@ + +
+ - WebSub +
-
+
Adopted Draft: @@to be filled later@@ +
Exclusion Draft: @@to be filled later@@ + Associated @@to be filled later@@ +
Exclusion Draft Charter: @@to be filled later@@ +
+ - Activity Streams +
-
+
Adopted Draft: @@to be filled later@@ +
Exclusion Draft: @@to be filled later@@ + Associated @@to be filled later@@ +
Exclusion Draft Charter: @@to be filled later@@ +
+ - Activity Vocabulary +
-
+
Adopted Draft: @@to be filled later@@ +
Exclusion Draft: @@to be filled later@@ + Associated @@to be filled later@@ +
Exclusion Draft Charter: @@to be filled later@@ + +
+ - Micropub +
-
+
Adopted Draft: @@to be filled later@@ +
Exclusion Draft: @@to be filled later@@ + Associated @@to be filled later@@ +
Exclusion Draft Charter: @@to be filled later@@ + +
+ - Linked Data Notifications +
-
+
Adopted Draft: @@to be filled later@@ +
Exclusion Draft: @@to be filled later@@ + Associated @@to be filled later@@ +
Exclusion Draft Charter: @@to be filled later@@ + +
+ - Webmention +
-
+
Adopted Draft: @@to be filled later@@ +
Exclusion Draft: @@to be filled later@@ + Associated @@to be filled later@@ +
Exclusion Draft Charter: @@to be filled later@@ + +
+
Success Criteria
+ ++ In order to update the Recommendation, each substantive change is expected to have + at least two independent + implementations of every feature defined in the specification, where interoperability can be + verified by passing open test suites, and two or more implementations interoperating with each other. + +
+ ++ Each substantive change should contain a section detailing all known security and privacy implications + for implementers, authors, and end users. +
+ ++ To promote interoperability, all changes made to specifications should have + tests. +
+ ++ This Working Group expects to follow the TAG Web + Platform Design Principles. +
+Coordination
+For all specifications, this Working Group will seek + horizontal review for + accessibility, internationalization, privacy, and security with the + relevant Working and Interest Groups, and with the + TAG. + Invitation for review must be issued during each major standards-track + document transition, including + FPWD. + The Working Group is encouraged to engage collaboratively with the + horizontal review groups throughout development of each specification. + The Working Group is advised to seek a review at least 3 months before + first entering + CR + and is encouraged to proactively notify the horizontal review groups + when major changes occur in a specification following a review. +
+ ++ This group is expected to coordinate with the + Social Web Incubator Community Group + on consensus-based proposals related to content changes for the + ActivityPub Maintenance Working Group Deliverables. + The Chairs of this group should reject proposals that are incompatible + with this Charter. +
+ +W3C Groups
+-
+
- Social Web Incubator Community Group +
- @@to be filled later@@ +
External Organizations
+-
+
- [other name] Working Group +
- [specific nature of liaison] +
+ Participation +
++ To be successful, this Working Group is expected to have 6 or more active + participants for its duration, including representatives from the key + implementors of this specification, and active Editors and Test Leads + for each specification. The Chairs, specification Editors, and Test + Leads are expected to contribute half of a working day per week towards + the Working Group. There is no minimum requirement for other Participants. +
++ The group encourages questions, comments and issues on its public + mailing lists and document repositories, as described in + Communication. +
++ The group also welcomes non-Members to contribute technical submissions + for consideration upon their agreement to the terms of the + W3C Patent Policy. +
+Participants in the group are required (by the + W3C Process) + to follow the W3C Code of Conduct. +
++ Communication +
++ Technical discussions for this Working Group are conducted in + public: + the meeting minutes from teleconference and face-to-face meetings will + be archived for public review, and technical discussions and issue + tracking will be conducted in a manner that can be both read and + written to by the general public. Working Drafts and Editor's Drafts + of specifications will be developed in public repositories and may + permit direct public contribution requests. + The meetings themselves are not open to public participation, however. +
++ Information about the group (including details about deliverables, + issues, actions, status, participants, and meetings) + will be available from the Social Web Maintenance Working Group home page. +
++ Most Social Web Maintenance Working Group teleconferences will focus on discussion + of particular specifications, and will be conducted on an as-needed basis. +
++ This group primarily conducts its technical work pick + one, or both, as appropriate: on the public mailing list + public-[email-list]@w3.org + (archive) + or on GitHub issues. + The public is invited to review, discuss and contribute to this work. +
++ The group may use a Member-confidential mailing list for administrative + purposes and, at the discretion of the Chairs and members of the group, + for member-only discussions in special cases when a participant requests + such a discussion. +
++ Decision Policy +
++ This group will seek to make decisions through consensus and due process, + per the + W3C Process Document (section 5.2.1, Consensus). + Typically, an editor or other participant makes an initial proposal, + which is then refined in discussion with members of the group and other + reviewers, and consensus emerges with little formal voting being required. +
++ However, if a decision is necessary for timely progress and consensus + is not achieved after careful consideration of the range of views + presented, the Chairs may call for a group vote and record a decision + along with any objections. +
++ 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 (for + example, via email, GitHub issue or web-based survey), with a response + period from [pick a duration within:] + one week to 10 working days, depending on the chair's + evaluation of the group consensus on the issue. + + If no objections are raised by the end of the response period, the + resolution will be considered to have consensus as a resolution of the + Working Group. +
++ 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. +
++ This charter is written in accordance with the + W3C Process Document (Section 5.2.3, Deciding by Vote) + and includes no voting procedures beyond what the Process Document requires. +
++ Patent Policy +
++ This Working Group operates under the + W3C Patent Policy + (Version of 15 September 2020). To promote the widest adoption of Web + standards, W3C seeks to issue Web specifications that can be implemented, + according to this policy, on a Royalty-Free basis. + + For more information about disclosure obligations for this group, please see the + licensing information. +
+ +Licensing
+This Working Group will use the + W3C Software and Document license for all its deliverables.
++ About this Charter +
++ This charter has been created according to + section 3.4 + of the Process Document. + In the event of a conflict between this document or the provisions of + any charter and the W3C Process, the W3C Process shall take precedence. +
+ ++ Charter History +
+ +The following table lists details of all changes from the initial + charter, per the W3C + Process Document (section 4.3, Advisory Committee Review of a Charter): +
+ +| + Charter Period + | ++ Start Date + | ++ End Date + | ++ Changes + | +
|---|---|---|---|
| + Initial Charter + | ++ [dd monthname yyyy] + | ++ [dd monthname yyyy] (start +2 years) + | ++ none + | +
Change log
+ + +Changes to this document are documented in this section.
+ +