This repository details how changes to the Solid Specification, Solid Roadmap, and Supporting Documentation may be proposed and accepted.
Anyone may participate in this process. Please read the Code of Conduct before doing so.
Any individual that has been involved in proposals to improve the Solid Specification, Solid Roadmap, or any Supporting Documentation, has provided a valuable service to the Solid Project and is encouraged to continue.
All manner of contributions are important - whether identifying problems, asking questions, or proposing normative changes.
There are many topics, problems, or ideas best tackled by a group of people with a specific set of domain expertise. For these cases, we have Solid Panels.
Solid Panels are groups of individuals focused on a specific problem or domain relevant to Solid, with an aim to propose changes to the Solid Specification, Solid Roadmap, and/or Supporting Documentation. Anyone may join a panel or suggest a new panel.
Domains may be technical, non-technical, or some combination of the two. For example, a Security Panel could focus on the evaluation and advancement of the Solid security model.
A list of Solid Panels is maintained at panels.md. This listing helps people find panels they may want to participate in, and helps editors find panels to consult as part of the editorial process.
Stakeholders are those affected by normative changes to the Solid Specification, Solid Roadmap, or Supporting Documentation. There are two types of Stakeholders; Solid Users and Solid Implementers. It is important to consider them both when proposing changes, and adhering to the W3C priority of constituencies is encouraged. A Stakeholder may be both a user and an implementer.
Stakeholders who have opted to identify themselves publicly are listed at stakeholders.md. Anyone may decide to identify themselves publicly as a Solid Stakeholder, but it is not mandatory. Identified stakeholders may be consulted for feedback as part of the editorial process.
Solid Users are individuals, companies, or organizations who access data stored in a Solid Pod.
Solid Implementers are companies or organizations who are implementing the Solid Specification. A Solid Implementer may be any combination of Identity Provider, Pod Provider, and Application Provider.
This section details how changes to the Solid Specification, Solid Roadmap, or Supporting Documentation may be drafted, proposed, and accepted.
Anyone may submit a proposal to alter this process. These proposals will not be reviewed by the editors. They will be reviewed only by Tim Berners-Lee, who is the Solid Director.
Anyone may propose improvements to the Solid Specification, Solid Roadmap, or Supporting Documentation. Here are some examples of different ways to contribute:
- Submit a pull request or issue on the Solid Specification repository in GitHub
- Make a suggestion to the Solid Authorization Panel chat room about a change you'd like to see in Web Access Control
- Make a suggestion on the Solid W3C Community Group mailing list to form a new Solid Panel, or join an existing Solid Panel
- Propose an item for the W3C Solid Community Group call
Proposals for substantive changes to the Solid Specification, Solid Roadmap, or Supporting Documentation go through an editorial review process. A change is considered substantive when it alters the normative text of the Solid Specification or the Solid Roadmap.
Any proposal must be realistic and reasonable to implement, preferably with example implementations, and demonstrable support from Implementers.
Any proposal should also be accompanied with a reasonable explanation of the need for the proposed change. For example:
- Adding a new capability that satisfies one or more new use cases, or to reflect a new capability already incorporated consistently into multiple implementations.
- Removing something because it was never adopted by Implementers for legitimate reasons, or because there has been a collective shift in focus away from that feature and it no longer makes sense to keep it.
- Changing something to a simpler design that is able to address the same use case(s) with less complexity, or a change that resolves one or more identified issues in real-world use.
A draft proposal often involves public discussion before being formally presented for review. After these discussions have occurred and a draft proposal has reached a sufficient level of maturity, it should be presented as a candidate proposal, asking Stakeholders and Panels if there are any major objections.
When there are objections, notify the Solid Panels and Stakeholders about the final proposal with an invitation to vote. If there are options, detail them along with the implications of the options. The final proposal needs to be open for one week to give others a chance to vote. To show your support for a proposal write +1. To show your disapproval for a proposal write -1 along with a detailed reason for the disapproval and a suggestion for a preferred alternative. To abstain type 0 when you have no opinion. If you do not vote by the end of the week it will be assumed that you abstain. At the end of the week anyone may publish an overview of the vote results per Solid Panel and Stakeholder.
Candidate proposals to the Solid Specification, Solid Roadmap, or Supporting Documentation submitted for review go through an editorial process before they are accepted.
Candidate proposals and the results of any vote related to the same need to be put forward to the editors for review. For the proposal to be accepted, three editors need to actively approve with no editors actively rejecting. Editors may abstain. A proposal must be open for at least one week before final acceptance. If an editor does not vote by the end of that week it will be assumed that the editor abstained.
Editors are appointed directly by the Solid Director. Editors are listed at editors.md along with their contact details and affiliations. Anyone may submit a request to be an editor. These requests are not reviewed by other editors. They are reviewed directly by the Solid Director.
The Solid Manager, who is also an editor, is appointed by the Solid Director. The Solid Manager is responsible for formalizing the outcome of any votes.
Administrators are granted privileged access to control the tools, systems, and services used for advancing the Solid Specification, Solid Roadmap, and Supporting Documentation. This includes the Solid GitHub organization, Solid Gitter channels, the Solid Forum, and the Solid Website.
Administrators are appointed directly the Solid Director. Administrators are listed at administrators.md along with their contact details and affiliations. Anyone may request to be an administrator. Administrator requests are not reviewed by other Administrators. They are reviewed only by the Solid Director.
The Solid Manager, who is also an administrator, is appointed by the Solid Director and is responsible for implementing the vision of the Solid Director.
Solid culture documentation was put together with inspiration and learnings from the following resources.
- W3C Good practice for running a group
- Python (2018) Python Lanugage
- Elinor Ostrom (2005) Understanding Institutional Diversity.
- Chales M Schweik and Meelis Kitsting (2010) Applying Elinor Ostrom’s Rule Classification Framework to the Analysis of Open Source Software Commons. Transnational Corporations Review
- Sean McDonald (2019) Reclaiming Data Trusts. CIGO
- Aymeric Augustin Django
- https://tc39.github.io/process-document/