Skip to content

Latest commit

 

History

History
209 lines (134 loc) · 20.8 KB

solid-cg-charter.md

File metadata and controls

209 lines (134 loc) · 20.8 KB
Raw
Document Status
Modified
2023-11-14
Reason
This document is no longer effective and is no longer being updated here. For the latest information on the W3C Solid Community Group, please refer to its repository, charter, and contributing guidelines.

W3C Solid Community Group Charter

  • Created: 2023-07-04
  • Modified: 2023-09-06
  • Effective: 2023-09-01
  • Version: 1.0

The aims of the Solid project are in line with those of the Web itself: empowerment towards "an equitable, informed and interconnected society" [ethical-web-principles]. Solid adds to existing Web standards to realise a space where individuals and communities can maintain their autonomy, control their data and privacy, and choose applications and services to fulfill their needs.

The mission of the Solid Community Group is to explore and describe the interoperability between different classes of products by using Web communication protocols, global identifiers, authentication and authorization mechanisms, data formats and shapes, notifications, and query interfaces.

The group will aim to give authors of technical reports and software implementers confidence that they can rely on the Solid ecosystem to deliver on the promise of interoperability based on open standards. Towards that end, the group will operate with a mutual understanding between contributors to technical reports, test suite software maintainers, and software implementers by following a cooperation process for the advancement of the Solid platform based on the Solid QA initiative.

As per W3C structures for groups and W3C Process, the Community Group will maintain its focus on incubating technical reports, prototyping software, and testing implementations within the Scope of the charter, with the aim of advancing mature works to the W3C Recommendation track in a Working Group.

The Solid community with various stakeholders comes together under the umbrella of the Solid Project, and thus the W3C Solid Community Group interacts and coordinates with the Project's organisation as a whole to help inform the work with the needs of the wider community.

Scope

In general, topics that are “in scope” include anything related to enabling affordances for decentralised Web applications to create and use data across decentralised storages in a way that is secure and privacy respecting for individuals and communities. Work items are intended to be compatible with or extend the Architecture of the World Wide Web. These topics include, but not limited to, the following:

  • Protocols for the storage, transmission and portability of data.
  • Authentication and authorization mechanisms.
  • Notifications.
  • Query interfaces.
  • (Meta)data models that can be used in storages, e.g., policies, data privacy and rights, provenance records and auditing, error messages.
  • Profile descriptions for social and software agents.
  • Data interoperability: sharing semantics of the content of resources, e.g., data shapes, data portability.
  • Service interoperability: sharing semantics on the discovery of actions and access to resources, e.g, web service descriptions, provisioning, portability.
  • User interface affordances: the display of data and services in a view.
  • Vocabularies providing the necessary semantics for the mechanisms defined within the scope of this group.
  • Signing messages.
  • Federation, e.g., message passing, trust, data cascading.
  • Evaluation tools (software programs or online services) that help determine implementation conformance.
  • Publishing test reports and communicating the level of adoption of technical reports.

With the exception of integrating or bridging specifications developed by another active community in an open standards development body that specialises in a particular topic, the Solid Community Group defer the work to the other community.

Out of Scope

In general, topics that are “out of scope” involve anything not directly related to the above. Some examples of these are listed here:

  • The relative merits of various economic, political, or sociological theories.
  • Marketing or evangelizing of technologies not intended to be released under a license compatible with W3C specifications. Discussion of out-of-scope solutions should be limited to elaborating upon technological advantages/disadvantages.
  • Community Group's Work Items that have transitioned to a deliverable of an active Working Group.

Work Items

The Community Group current work items are listed at Solid Technical Reports.

In general, all documents in scope of the group are welcome. If there are individuals who will commit to being editors for a document, the group should agree to accept it as a work item even if it conflicts with previous work adopted by the community. Newly-accepted work items that extend beyond the scope of this Community Group Charter will lead to a reconsideration of the Charter. The Community Group may vote to revise the Charter in order to include new work, or to determine that the proposed work is unrelated.

The work item process is outlined here.

Coordination

The group will make good faith efforts to include the following communities in the progress of our work.

The group expects to follow the following W3C Recommendations, Guidelines, and Notes, and, if necessary, to liaise with the communities behind them:

Participation

The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication

The Solid Technical Reports Contributing Guide is available to all participants of the group that would like to make substantive contributions.

Communication

Technical discussions for this Community 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. Work items will be developed in public repositories and may permit direct public contribution requests. The meetings themselves are open to public participation.

Most Solid Community Group teleconferences will focus on discussion of particular specifications and QA work, and will be conducted on an as-needed basis.

This group primarily conducts its technical work through:

The public mailing list public-solid@w3.org may be used for general discussions and announcements.

Decision Policy

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 of five to ten 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 Community 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.

License

The group will use W3C copyright licenses for all its work items except any software code artifacts, for which the group will use the MIT license.

  • Per W3C Process, all contributions to the group fall under the W3C Community Contributor License Agreement (CLA).

  • When finalizing a W3C Community Group Draft Report towards a W3C Community Group Final Report, e.g., to transition the report to a Working Group, the group will contact all actual contributors to the report to secure their commitment to the W3C Final Specification Agreement (FSA).

    Note that the intention of this group is to propose its documents as Technical Reports to a Working Group, where the published documents will fall under the W3C Document License.

  • In accordance with the CLA, the group licenses all its software artifacts under the W3C Software license, but without the notification obligation.

    Note that the intention of this group is to propose its software artifacts and code snippets included in documents to be part of a Working Group's Technical Reports, where they will fall under the W3C Software License, but without notification obligation; any W3C Authoritative Test Suite a Working Group publishes will fall under a dual license combining the W3C Test Suite License and the W3C's 3-clause BSD license.

The group strongly encourages its participants, as well as other stakeholders in the Solid ecosystem, to use the MIT license, or another OSI approved license, for any open source software conforming to Solid specifications.

Community Group Process

Anything in this charter that conflicts with requirements of the Community and Business Group Process is void.

Unless otherwise stated, the Community Group will follow or aim to be compatible with the W3C Process.

Participation and Voting Rights

A general participant of the Community Group can be an individual representing themself or an organization. Consistent with W3C rules, in order to formally join the Community Group, a participant must have a W3C account and push the “Join” button for the Community Group. However, W3C membership is not required to have a W3C account nor to join the Community Group.

Any participant of the Community Group who has also accepted the W3C Community Contributor License Agreement (CLA) as part of the enrollment process is eligible to vote on elections, charter amendments, and other community matters so long as they have completed enrollment by the date that the chairs announce those events to the public mailing list.

The Chairs will determine the list of eligible voting participants as of the record date. The Chairs will make the list available to the Community Group two weeks before every election that requires voting participants to be carefully identified, and the list will be verified by a third party such as a member of W3C staff or a neutral community member for which there are no strong objections. If the voting list is not ready, then the election date will be moved until two weeks after it is ready. If the third party has reasonable objections, the election will be delayed until two weeks after such objections are resolved.

Chairs

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

The Community Group participants appoints (and re-appoints) Chairs for the group.

The chair and the W3C Team Contact of the group SHOULD NOT be the same individual.

Participation as Chair afforded to the specific individuals elected or appointed 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 and elected chairs per term MUST have unique affiliations.

An affiliation MAY submit one ballot that ranks candidates in their preferred order.

Choosing a Chair

  • 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 any 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.

Removing a Chair

  • Chairs may 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 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 are not addressed, they may then escalate to a public call for a no confidence vote. If after 60 days, the participant has not made that call for a no confidence vote, the matter is 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 and the names and emails of at least 3 participants of the group who thereby call for a recall. This announcement must come from the participant who initiated the private communication with the chairs to discuss their concerns. The other two 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.
  • 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 re-election.
  • 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

  • Chairs may propose amendments to the charter by asking for a call for principled objections to the new charter. If, after a period of two weeks, no principled objections have been presented by a current participant of the group, the new charter is approved.
  • If a principled objection is posted to the mailing list or expressed in a regular call, then the chairs may either drop the amendment or proceed with a public vote.
  • A public vote for a new charter must be called by the chairs within two weeks of the principled objection.
  • Such a vote will be open for two weeks, with ballots cast via the group’s public mailing list. Each participant of the group may cast one ballot, “yea” or “nay”. A new charter must receive “yea” on two-thirds of the votes cast in the ranked choice vote, and the total votes cast must represent 5% or greater of the group participants, to pass.
  • The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.
  • Changes to the Coordination does not constitute an amendment to the charter that requires a rechartering vote.