├── LICENSE.md ├── README.md ├── administrators.md ├── code-of-conduct.md ├── creators.md ├── dei-team.md ├── draft-working-group-charter ├── charter-style.css ├── index.html ├── pubrules-style.css ├── w3c_home.svg └── w3cdoc.css ├── editors.md ├── gitter-chat-overview.md ├── librarians.md ├── notifications-panel-charter.md ├── panels.md ├── repo-overview.md ├── solid-cg-charter.md ├── solid-editors-tr-phases.svg ├── solid-editors-tr-process.md ├── stakeholders.md ├── system-operators.md └── test-suite-panel-charter.md /LICENSE.md: -------------------------------------------------------------------------------- 1 | Copyright 2019 - present 2 | 3 | Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: 4 | 5 | The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. 6 | 7 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 8 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | This repository details how changes to Solid may be proposed and accepted. 2 | 3 | # Solid Specification 4 | The following describes how changes to the specifications in the Solid ecosystem may be proposed and accepted. Anyone may submit a proposal to alter this process; such proposals will be approved only by [Tim Berners-Lee](https://github.com/timbl), who is the Solid Director. 5 | 6 | Development in the Solid ecosystem occurs in the [Solid Specifications](https://github.com/solid/specification) repository. The deprecated [Unofficial Draft](https://github.com/solid/solid-spec) predating current development is still available for historical reference. 7 | 8 | Anyone may participate in this process. Please read the [Code of Conduct](code-of-conduct.md) before doing so. 9 | 10 | ## Editorial Team 11 | 12 | The Solid [Editorial Team](https://github.com/orgs/solid/teams/editors) is responsible for the implementation of the Solid Specification process. Members of the Editorial Team are appointed by the Solid Director. The Editorial Team is comprised of all the Editors appointed by the Solid Director, who are listed at [editors.md](editors.md), along with their assignments, contact details, and affiliations. The Editorial Team shepherds Solid and coordinates with those who participate in [Solid Panels](#solid-panels) and with [Stakeholders](#stakeholders) and [Implementers](#implementers). The Solid Director may also appoint support personnel on an as-needed basis, such as a Release Manager, for organizing the workflow of the specification process. 13 | 14 | Anyone may apply to be an Editor, and must include one or more requested editorial assignments as part of their application. These requests are reviewed only by the Solid Director. Editor applications that can demonstrate the support of a relevant panel or group of community members will be favorably considered. 15 | 16 | ## Contributors 17 | 18 | Any individual who has been involved in proposals to improve the [Solid Specification](https://github.com/solid/specification) has provided a valuable service to the [Solid Project](https://www.solidproject.org) and is encouraged to continue. 19 | 20 | Contributions are welcome, including identifying problems, asking questions, and proposing normative changes. 21 | 22 | There are many topics, problems, or ideas best addressed by a group of contributors with specific domain expertise in [Solid Panels](#solid-panels). 23 | 24 | ### Solid Panels 25 | 26 | Solid Panels are groups of contributors focused on a specific problem or domain relevant to Solid, with an aim to propose changes to the [Solid Specification](https://github.com/solid/specification). 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. Only those who have agreed to the [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/) may participate in a Solid Panel. 27 | 28 | New panels may be proposed by submitting an issue to the [solid/process](https://github.com/solid/process) repository. Establishing a new panel requires the endorsement of at least one member of the Editorial Team. To receive endorsement, the proposed panel submission must include: 29 | 30 | 1. A stated purpose 31 | 1. One or more initiatives that will be actively pursued and tracked in regular panel sessions to advance the stated purpose 32 | 1. Demonstrable support of at least five prospective participants 33 | 34 | The panel proposal can be revised until at least one member of the Editorial Team endorses the proposal. Submissions that fail to receive endorsement may be removed by Solid Administrators after 3 months. 35 | 36 | Any Editor endorsing a panel is expected to attend the panel regularly, and to provide the panel insight on specification priorities and support the work of the panel. 37 | 38 | Each panel is chaired by one or more Panel Chairs. An Editorial Team member endorsing a panel is responsible for appointing the Panel Chairs, barring any objections from another Editor, another Panel Chair of the same panel, or objection from a majority of panel members. The Solid Director reserves the right to appoint and/or change Panel Chairs. In the event that an Editor is nominated as a Panel Chair, they must be appointed by another member of the Editorial Team. 39 | 40 | Responsibilities of a Panel Chair include but are not limited to: 41 | 42 | - Coordinating and communicating panel initiatives 43 | - Working with Editors on prioritizing panel initiatives 44 | - Ensuring panel meetings are focused on advancing panel initiatives 45 | - Ensuring every panel meeting has a clear goal and agenda 46 | - Ensuring all actions arising from meetings are tracked to completion 47 | - Ensuring target dates are set for objectives 48 | - Ensuring panel decisions, activities, and achievements are tracked and communicated 49 | 50 | Specification changes proposed by a panel are subject to the [proposal review process](#reviewing-proposals). 51 | 52 | Those interested in participating in a panel can find a list of active panels at [panels.md](panels.md). 53 | 54 | Panels may request to have a repository created within the [Solid Github Organization](https://github.com/solid) by creating an issue in [solid/process](https://github.com/solid/process). The request should include the proposed name of the repository and how it will be used. Any editor may reject a proposed name and request an alternative. All panel members will receive [_Maintain Permissions_](https://help.github.com/en/articles/repository-permission-levels-for-an-organization#permission-levels-for-repositories-owned-by-an-organization) on the panel repository. Panel repositories that are inactive for more than six months may be archived by Solid Administrators. 55 | 56 | Panels may request to have a gitter channel created within the [Solid Gitter Organization](https://gitter.im/solid) by creating an issue in [solid/process](https://github.com/solid/process). 57 | 58 | Panels that become inactive can be closed by a majority vote of the Solid Editors. 59 | 60 | ## Stakeholders 61 | 62 | Stakeholders are those affected by normative changes to the [Solid Specification](https://github.com/solid/specification). There are two types of Stakeholders: [Solid Users](#solid-users) and [Solid Implementers](#solid-implementers). It is important to consider them both when proposing changes, and adhering to the W3C Web Platform Design Principles' [Priority of Constituencies](https://www.w3.org/TR/design-principles/#priority-of-constituencies) is encouraged. A Stakeholder may be both a user and an implementer. 63 | 64 | Stakeholders who have opted to identify themselves publicly are listed at [stakeholders.md](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. 65 | 66 | ### Implementers 67 | 68 | Solid Implementers are organizations who are implementing the [Solid Specification](https://github.com/solid/specification). A Solid Implementer may be any combination of Identity Provider, Pod Provider, Application Provider, or a provider of other Solid-related functionality. 69 | 70 | ## How to Make Changes 71 | 72 | This section details how changes to the [Solid Specification](https://github.com/solid/specification) may be drafted, proposed, and accepted. 73 | 74 | ### Drafting proposals 75 | 76 | Anyone may propose improvements to the [Solid Specification](https://github.com/solid/specification), which should be submitted as a pull request or issue on the [Solid Specification repository](https://github.com/solid/specification) in GitHub. Proposals for substantive changes to the [Solid Specification](https://github.com/solid/specification) 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. 77 | 78 | Any proposal should also be accompanied with a reasonable explanation of the need for the proposed change. For example: 79 | 80 | - Adding a new capability to satisfy one or more new use cases, or to reflect a capability that has already been implemented. 81 | - 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. 82 | - 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. 83 | 84 | A draft proposal often involves public discussion before being formally presented for review. Stakeholders and Panels may provide feedback on draft proposals. 85 | 86 | ### Reviewing proposals 87 | 88 | Candidate proposals to the [Solid Specification](https://github.com/solid/specification) submitted for review go through an editorial process before they are accepted. 89 | 90 | The [Solid Editors](https://github.com/orgs/solid/teams/editors) [maintain a monthly development cycle](solid-editors-tr-process.md) in which they select proposals and issues from the open issues and proposals for consideration. 91 | 92 | The Editors typically meet weekly, with an agenda put forward by the Solid Director with the help of other Editors and the Release Manager. In the interest of transparency, these meetings are to be recorded and made public within two days of the meeting. 93 | 94 | To help broad consensus form, it is suggested that each proposal be brought to the attention of the Editors at some defined contact points during its life cycle. These contact points are: 95 | 1. When a reason to change or extend the specification is first encountered, an [issue can be created](https://github.com/solid/specification/issues/new). The issue can then be used for further communication with the Editors. 96 | 1. Panels may create or adopt issues, and Panels should notify Editors that such discussion has started. 97 | 1. When a Panel reaches rough consensus on an issue, the Panel should notify the Editors, indicating in informal text what the consensus entails and who participated in forming it. 98 | 1. When a Panel starts drafting the text of a proposal, the Panel should notify the Editors. 99 | 100 | The above is not required and may be superfluous for small changes, but is likely to speed up the overall process for larger issues. 101 | 102 | An Editor determines whether a Candidate Proposal includes a substantive change and marks it accordingly. If there is any disagreement among Editors, the Candidate Proposal will be automatically marked as including a substantive change. 103 | 104 | When a proposal is first submitted, the Solid Editors will assign a single Editor as the shepherd for the proposal and assign a time window for review and its acceptance or rejection; the time window will be either 1 or 2 months from the date of proposal submission, depending on the complexity of the proposal. If an Editor is a contributor to the proposal, they will not be assigned as the proposal's shepherd. This time window includes all discussion and revision that may be needed to improve the proposal. The Solid Director, working with the Solid Editors and any administrative support personnel, will maintain a dashboard of open and closed proposals, time windows for review, and review status. 105 | 106 | If a contributor disapproves of Candidate Proposal that is under consideration, they must provide substantive, written comments that contain proposed remedies to the Solid Editors at least 1 week before the end of the review time window. The Solid Editors will consider the comments and suggest possible remedies. 107 | 108 | Candidate Proposals with substantive changes must be responsive to comments and objections. If rough consensus to approve the proposal cannot be reached among the Solid Editors, a vote must be taken during an Solid Editors meeting, and the advancement of the proposal can be blocked by a negative vote by 1/3 of all Editors. Once the Candidate Proposal has successfully passed editorial review, it is merged by its shepherd. The shepherd for a proposal is responsible for ensuring a resolution of the proposal within the time window, and if the shepherd is unable to complete the proposal review during the time window, the Solid Director will appoint a different Editor as shepherd and extend the time window for the proposal by 1 month. If a proposal is not approved, the proposer may resubmit it in revised form no sooner than one month after the final review by the Solid Editors. 109 | 110 | Candidate Proposals without substantive changes require one Editor assigned to the material being modified to actively approve the proposal, with no Editors from the Editorial Team actively rejecting, and may be merged immediately by an assigned Editor. The assigned Editor who is shepherding may approve and merge their own non-substantive changes. Anyone from the Editorial Team has the right to revert a non-substantive change, but are encouraged to communicate with the assigned Editor who merged it first. Any revert must be accompanied by a reasonable explanation. If the change is reverted because they believe it to be substantive, that must be included in the explanation. 111 | 112 | ### Vocabulary Management 113 | 114 | The [W3C Solid Community Group](https://www.w3.org/community/solid/) handles the management of Solid vocabularies under its responsibility through the [solid/vocab](https://github.com/solid/vocab) repository. 115 | 116 | The policy for the management of Solid vocabularies under the W3C namespace is described in [Adding to W3C RDF Namespaces](https://www.w3.org/2016/08/namespaces/). 117 | 118 | ### Repositories 119 | 120 | Repositories requiring editorial review are listed in [editors.md](editors.md#editorial-assignments). Each repository has one or more assigned editors, and only assigned editors are permitted to merge into the main branch of these repositories, per the [proposal review process](#reviewing-proposals). 121 | 122 | Editors have [_Admin Permissions_](https://help.github.com/en/articles/repository-permission-levels-for-an-organization#permission-levels-for-repositories-owned-by-an-organization) on the repositories they are assigned to, and are permitted to grant [_Write Permissions_](https://help.github.com/en/articles/repository-permission-levels-for-an-organization#permission-levels-for-repositories-owned-by-an-organization) to other contributing authors on the same. All Editors have [_Write Permissions_](https://help.github.com/en/articles/repository-permission-levels-for-an-organization#permission-levels-for-repositories-owned-by-an-organization) on all repositories requiring editorial review listed in [editors.md](editors.md). 123 | 124 | # Solid QA 125 | 126 | [Solid QA](https://solidproject.org/ED/qa) policy, processes, and procedures are developed through the [Test Suite Panel](https://github.com/solid/test-suite-panel/) as per the [Test Suite Panel Charter](https://github.com/solid/process/blob/main/test-suite-panel-charter.md) with the aim to give authors of technical reports and implementers of software confidence that they can rely on the Solid ecosystem to deliver on the promise of interoperability based on open standards. 127 | 128 | # Administration 129 | 130 | Administrators are granted privileged access to control the tools, systems, and services used for advancing the Solid. This includes the [Solid GitHub](https://github.com/solid) organization, [Solid Gitter](https://gitter.im/solid/home) channels, the [Solid Forum](https://forum.solidproject.org), and the [Solid Website](https://www.solidproject.org). 131 | 132 | Administrators belong to the [Administrators Team](https://github.com/orgs/solid/teams/administrators) in the [Solid GitHub Organization](https://github.com/solid) and have [_Admin Permissions_](https://help.github.com/en/articles/repository-permission-levels-for-an-organization#permission-levels-for-repositories-owned-by-an-organization) on all repositories therein. Administrators have [_Owner Permissions_](https://help.github.com/en/articles/permission-levels-for-an-organization#permission-levels-for-an-organization) for the [Solid GitHub Organization](https://github.com/solid). 133 | 134 | The Solid World Coordination Administrator is granted privileged access to such tools, systems, and services as are required to coordinate and promote the monthly Solid World webinar, such as Vimeo, Twitter, Eventbrite, Typeform, and/or others. 135 | 136 | ### Becoming an Administrator 137 | 138 | Administrators are appointed by the Solid Director. Administrators are listed at [administrators.md](administrators.md) along with their contact details and affiliations. Anyone may apply to be an Administrator. Administrator applications are reviewed only by the Solid Director. 139 | 140 | # Solidproject.org Website 141 | 142 | [Creators](https://github.com/solid/process/blob/master/creators.md) independently assist with keeping [solidproject.org](https://solidproject.org/) up to date. 143 | 144 | Anyone can make suggestions by creating issues or submitting pull requests 145 | to the [solid/solidproject.org](https://github.com/solid/solidproject.org) repository. 146 | 147 | Minor changes (such as spelling, grammar, and broken links) do not require review. 148 | Larger chunks of texts should be reviewed by a Creator or Editor for technical correctness. 149 | Changes to the main messaging require an approving review by the Director. 150 | 151 | # Solidcommunity.net 152 | 153 | [Solidcommunity.net](https://solidcommunity.net) is a free pod hosting service 154 | maintained by the Solid Project for research, development, and experimental, 155 | non-commercial use of Solid by community members. 156 | 157 | It is administered by [System Operators](system-operators.md), with additional 158 | support from Solid Project [Administrators](https://github.com/solid/process/blob/main/administrators.md). System Operators 159 | are appointed by the Solid Director. 160 | -------------------------------------------------------------------------------- /administrators.md: -------------------------------------------------------------------------------- 1 | # Solid Administrators 2 | 3 | Below is a listing of [Solid Administrators](README.md#administration). Administrators are granted privileged access to control the tools, systems, and services used for advancing the Solid Specification, Solid Roadmap, and Supporting Documentation. 4 | 5 | | Name | WebID | 6 | | --------- | ---------- | 7 | | [Tim Berners-Lee](https://github.com/timbl) | [WebID](https://www.w3.org/People/Berners-Lee/card#i) | 8 | | [Alain Bourgeois](https://github.com/bourgeoa) | [WebId](https://bourgeoa.solidcommunity.net/profile/card#me) | 9 | -------------------------------------------------------------------------------- /code-of-conduct.md: -------------------------------------------------------------------------------- 1 | # Solid Community Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | We as members of the Solid community pledge to make participation in our 6 | community a harassment-free experience for everyone, regardless of age, body 7 | size, visible or invisible disability, ethnicity, sex characteristics, gender, 8 | gender identity and expression, level of experience, education, socio-economic 9 | status, nationality, personal appearance, race, caste, color, religion, or 10 | sexual identity and orientation. 11 | 12 | We pledge to act and interact in ways that contribute to an open, welcoming, 13 | diverse, inclusive, and healthy community. 14 | 15 | In addition to this Code of Conduct, we adhere to the [Positive Work Environment 16 | at W3C: Code of Ethics and Professional 17 | Conduct](https://www.w3.org/Consortium/cepc/). 18 | 19 | ## About this Code of Conduct 20 | 21 | This Code of Conduct is maintained by the Code of Conduct Committee. 22 | 23 | Changes to this document need to be approved by the Code of Conduct Committee 24 | and the Solid Director. 25 | 26 | If you have any questions about this document, please direct them to the Code of 27 | Conduct Committee. 28 | 29 | If you experience a situation that is not covered by this Code of Conduct, 30 | please get in touch with the Code of Conduct Committee. 31 | 32 | If you would like to propose changes or improvements to this document, please 33 | create an issue and explain the changes you would like to see for consideration 34 | of the Code of Conduct Committee. 35 | 36 | ## Standards of Behavior 37 | 38 | Examples of behavior that contributes to a positive environment for our 39 | community include: 40 | 41 | * Demonstrating empathy and kindness toward other people 42 | * Being respectful of differing opinions, viewpoints, and experiences 43 | * Giving and gracefully accepting constructive feedback 44 | * Accepting responsibility and acknowledging harm caused to those affected by 45 | our mistakes, and learning from the experience 46 | * Focusing on what is best not just for us as individuals, but for the overall 47 | community 48 | 49 | * Asking for confirmation instead of assuming 50 | * Taking constructive actions, and move towards consensus when possible 51 | 52 | Examples of unacceptable behavior include: 53 | 54 | * The use of sexualized language or imagery, and sexual attention or advances of 55 | any kind 56 | * Trolling, insulting, derogatory or demeaning comments, and personal or 57 | political attacks 58 | * Communicating in a tone and language that could lead to creating a hostile and 59 | unwelcoming environment 60 | * Public or private harassment or threats. Harassment includes: offensive 61 | comments related to age, body size, visible or invisible disability, 62 | ethnicity, sex characteristics, gender, gender identity and expression, level 63 | of experience, education, socio-economic status, nationality, personal 64 | appearance, race, caste, color, religion, or sexual identity and orientation 65 | of an individual or group, unwelcome comments relating to any aspect of a 66 | person's lifestyle choices and personal life, deliberate misgendering and use 67 | of "dead" or rejected names, stalking and intimidation 68 | * Publishing others' private information, such as a physical or email address or 69 | any aspect of a person's identity, without their explicit permission 70 | * Other conduct which could reasonably be considered inappropriate in a 71 | professional setting 72 | 73 | ## Enforcement Responsibilities 74 | 75 | Instances of Code of Conduct violations will be handled by the Code of Conduct 76 | Committee. 77 | 78 | The Code of Conduct Committee are responsible for clarifying and enforcing our 79 | standards of acceptable behavior and will take appropriate and fair corrective 80 | action in response to any behavior that they deem inappropriate, threatening, 81 | offensive, or harmful. 82 | 83 | The Code of Conduct Committee have the right and responsibility to remove, edit, 84 | or reject comments, commits, code, wiki edits, issues, and other contributions 85 | that are not aligned to this Code of Conduct, and will communicate reasons for 86 | moderation decisions when appropriate. 87 | 88 | ## Scope 89 | 90 | This Code of Conduct applies within all community spaces, including but not 91 | limited to the Gitter chat rooms, Solid forum, and GitHub repositories, and also 92 | applies when an individual is officially representing the community in public 93 | spaces. Examples of representing our community include using an official e-mail 94 | address, posting via an official social media account, or acting as an appointed 95 | representative at an online or offline event. 96 | 97 | ## Enforcement 98 | 99 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 100 | reported to the Code of Conduct Committee by contacting any of its members: 101 | 102 | * [Osmar Olivo](https://github.com/oolivo) <oz@inrupt.com> 103 | * [Virginia Balseiro](https://github.com/VirginiaBalseiro) 104 | <info@virginiabalseiro.com> 105 | * [Alain Bourgeois](https://github.com/bourgeoa) 106 | <alain.bourgeois10@gmail.com> 107 | * [Sarven Capadisli](https://github.com/csarven) 108 | <info+solid+coc@csarven.ca> 109 | * [April Daly](https://github.com/LabObjects) 110 | <adaly@labobjects.com> 111 | 112 | Committee members will recuse themselves if they are the alleged harasser or the 113 | victim of a private harassment incident. 114 | 115 | All reports of violations will be reviewed and investigated promptly and fairly. 116 | 117 | All community members are obligated to respect the privacy and security of the 118 | reporter of any incident. Reports will be handled under confidentiality. 119 | 120 | Individuals who wish to join the committee can initiate the process by reaching 121 | out to any existing member. Upon initial approval, they can submit a pull request 122 | to be included in the committee's member list. 123 | 124 | To leave the committee, individuals can submit a pull request to be removed 125 | from the committee's member list. 126 | 127 | ## Enforcement Guidelines 128 | 129 | The Code of Conduct Committee will follow these Community Impact Guidelines in 130 | determining the consequences for any action they deem in violation of this Code 131 | of Conduct: 132 | 133 | ### Continued behavior 134 | 135 | A pattern of continued violations of community standards will be determined 136 | using a "three-strikes system". 137 | Three strikes will constitute a pattern of behavior, and it may lead to a 138 | temporary ban. Continued violations beyond three strikes may lead to a permanent 139 | ban. However, severe offenses may lead to a temporary or permanent ban 140 | regardless of the number of strikes. This applies to all violations of the Code 141 | of Conduct as described below. 142 | 143 | ### 1. Correction 144 | 145 | **Community Impact**: Use of inappropriate language or other behavior deemed 146 | unprofessional or unwelcome in the community. 147 | 148 | **Consequence**: A private, written warning from the Code of Conduct Committee, 149 | providing clarity around the nature of the violation and an explanation of why 150 | the behavior was inappropriate. 151 | 152 | ### 2. Warning 153 | 154 | **Community Impact**: A violation through a single incident or series of 155 | actions. 156 | 157 | **Consequence**: A warning with consequences for continued behavior. No 158 | unsolicited interaction with the people involved in the incident(s), including 159 | unsolicited interaction with those enforcing the Code of Conduct, for a 160 | specified period of time. This includes avoiding interactions in community 161 | spaces as well as external channels like social media. Violating these terms may 162 | lead to a temporary or permanent ban. 163 | 164 | ### 3. Temporary Ban 165 | 166 | **Community Impact**: A serious violation of community standards, including 167 | sustained inappropriate behavior. 168 | 169 | **Consequence**: A temporary ban from any sort of interaction or public 170 | communication with the community for a specified period of time. No public or 171 | private interaction with the people involved, including unsolicited interaction 172 | with those enforcing the Code of Conduct, is allowed during this period. 173 | Violating these terms will lead to a permanent ban. 174 | 175 | ### 4. Permanent Ban 176 | 177 | **Community Impact**: Demonstrating a pattern of violation of community 178 | standards, including sustained inappropriate behavior, harassment of an 179 | individual, or aggression toward or disparagement of classes of individuals. 180 | 181 | **Consequence**: A permanent ban from any sort of public interaction within the 182 | community. 183 | 184 | ## Attribution 185 | 186 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], 187 | version 2.1, available at 188 | [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1]. 189 | 190 | Community Impact Guidelines were inspired by [Mozilla's code of conduct 191 | enforcement ladder][mozilla coc]. 192 | 193 | For guidelines on how to give constructive and positive feedback, please see 194 | [How to give better 195 | feedback](https://www.virginiabalseiro.com/blog/feedback.html). 196 | 197 | For answers to common questions about this code of conduct, see the FAQ at 198 | [https://www.contributor-covenant.org/faq][faq]. Translations are available at 199 | [https://www.contributor-covenant.org/translations][translations]. 200 | 201 | [homepage]: https://www.contributor-covenant.org 202 | [v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html 203 | [mozilla coc]: https://github.com/mozilla/diversity 204 | [faq]: https://www.contributor-covenant.org/faq 205 | [translations]: https://www.contributor-covenant.org/translations 206 | -------------------------------------------------------------------------------- /creators.md: -------------------------------------------------------------------------------- 1 | Below is a record of the Creators who are appointed by the Solid Director. 2 | 3 | | Name | WebID | 4 | | --------- | ---------- | 5 | | [Jeff Zucker](https://github.com/jeff-zucker) | https://jeff-zucker.solidcommunity.net/profile/card#me | 6 | | [Ted Thibodeau](https://github.com/TallTed) | http://id.myopenlink.net/dataspace/person/tthibodeau#this | 7 | | [Kyra Assaad](https://github.com/kyraassaad) | https://pod.inrupt.com/kyra/profile/card#me | 8 | | [Virginia Balseiro](https://github.com/VirginiaBalseiro) | https://virginiabalseiro.com/#me | 9 | | [Michiel de Jong](https://github.com/michielbdejong) | https://michielbdejong.solidcommunity.net/profile/card#me | 10 | | [Hadrian Zbarcea](https://github.com/hzbarcea) | https://hadrian.solidcommunity.net/profile/card#me | 11 | | [Giselle Wenban](https://github.com/gisellewenban) | https://id.inrupt.com/gisellewenban | 12 | | [Timea Turdean](https://github.com/timea-solid) | https://timea.solidcommunity.net | 13 | -------------------------------------------------------------------------------- /dei-team.md: -------------------------------------------------------------------------------- 1 | # Diversity, Equity, and Inclusion Team 2 | 3 | ## Purpose 4 | This charter sets out to explain the Diversity, Equity, and Inclusion Team (DEIT). It provides a concise overview of our mission which is increasing voices in the Solid community by inviting individuals from all underrepresented groups. The team shall review interactions, make sure there are equal and supportive opportunities for those in underrepresented groups, and make recommendations to the Solid Team and Community. 5 | 6 | ## Membership 7 | The Team shall consist of both chair members and community members. All chair members and community members join on a volunteer basis. The chair members are appointed by the Director of Solid and serve an indefinite term. Elections are during the first quarter of the year. The prospective chair candidate can self-nominate, or be nominated by a member’s suggestion. The current chairs are: 8 | 9 | * Chair: [Sarven Capadisli](https://csarven.ca/#i) 10 | * Chair: Jeff Zucker 11 | * Chair: Kyra Assaad 12 | * Chair: [Virginia Balseiro](https://virginiabalseiro.com/#me) 13 | 14 | The Director of Solid and chair members will determine the number of community members, always greater than two, to meet or exceed regulatory requirements. All those in a chair member role must disclose relevant ties to organizations/companies/directorships and inform the DEIT of any changes to these when such changes take place. At this time, there are no issues with having multiple affiliations in the Solid community. Anyone can join. The administrators shall establish and approve formal and transparent remuneration policies and procedures for all team members. Chair members do not get paid any director fees. No fees will be required to join. 15 | 16 | ## Authority 17 | The DEIT has no expressed or implied power or authority above any other Teams in Solid. The DEIT will hold other Solid Teams accountable in all significant decisions and changes the DEIT makes for the community. The work that we are invested in is written below. 18 | 19 | * Increasing diversity, inclusion, and equity throughout the Solid community/ecosystem 20 | Making recommendations to the Solid Team and Director of Solid to increase opportunities for all underrepresented groups to make changes 21 | * Advocating for the community 22 | If either the Solid Team members or community member do not comply with the DEIT’s recommendations or policies. In that case, it will be up to the Solid Team to remedy and/or resolve. They will take action on a case-by-case basis by consulting with the DEIT. 23 | * Measuring the success behind our recommendations 24 | Surveys are offered to various community groups to assess education level, expertise, accessibility/disability, gender, and underrepresented groups. 25 | Focus groups will be gathered to report on progress; better see how we can support outside groups or individuals to join or thrive in Solid. 26 | 27 | ## Responsibilities 28 | The DEIT Chairs will report their activities to the Director of Solid, in summary, published quarterly. 29 | Creating a plan for diversity and inclusion with best practices in the Solid project. Also working alongside the W3C’s Positive Work Environment Community Group. 30 | 31 | Increase outreach of Solid’s work into communities with underrepresented groups. 32 | 33 | Achieve gender equity building a voice, volunteer/job opportunities, and work in the Solid community. 34 | 35 | ## Meetings 36 | The DEIT will meet at least quarterly and more often as needed. A majority of the community members shall constitute a quorum. The lead chair will keep a copy of the DEIT meeting minutes and forward a copy to the board secretary. The chair members may invite any director, officer, staff member, expert, or other advisor who isn’t a committee member to sit in, listen, and advise; however, these individuals will have no voting power. 37 | 38 | The DEIT will review its charter twice a year and recommend any proposed changes to the board for review. This document will also be available to the public. If you would like to make changes, please submit a PR. 39 | 40 | This charter was written by Marrelle Bailey, approved by the Solid Team on February 25, 2021, and last updated on April 28, 2021. 41 | -------------------------------------------------------------------------------- /draft-working-group-charter/charter-style.css: -------------------------------------------------------------------------------- 1 | #template h1 { clear: none } 2 | 3 | form { width: 90%; 4 | background: #eee5de; 5 | color: black; 6 | border: thin black solid; 7 | padding: .5em; 8 | margin-bottom: 1em; 9 | margin-left: auto; 10 | margin-right: auto 11 | } 12 | 13 | body { counter-reset: h2; } 14 | 15 | h2.nocount:before { content: "" } 16 | 17 | h2:before { 18 | content: counter(h2) ". "; 19 | display: inline; 20 | } 21 | 22 | h2.nocount { 23 | counter-increment: none; 24 | counter-reset: none 25 | } 26 | 27 | h2 { 28 | counter-increment: h2; 29 | counter-reset: h3; 30 | } 31 | 32 | h3:before { 33 | content: counter(h2) "." counter(h3) " "; 34 | display: inline; 35 | } 36 | 37 | h3 { counter-increment: h3; } 38 | 39 | h4 { margin-left: 0 } 40 | 41 | tfoot 42 | { 43 | font-size: 0.9em; 44 | font-style: italic; 45 | background-color: #ddd; 46 | } 47 | 48 | td.meeting { background: #FFE } 49 | td.WD1 { background: #FED } 50 | td.LC { background: #FCB } 51 | td.CR { background: #FA9 } 52 | td.PR { background: #F87 } 53 | td.REC { background: #F60 } 54 | td.note { background: #F60 } 55 | 56 | .toadd { background-color: #FF0; font-style: italic} 57 | 58 | strong.must { color: #F30; } 59 | 60 | strong.should { color: #C63; padding: 0; border: none } 61 | .should { 62 | padding: .25em; 63 | border: thin #C63 solid; 64 | } 65 | 66 | li.may, strong.may { color: #99C; } 67 | div.may { 68 | padding: 3px; 69 | background-color: #e2edfe; 70 | border: 1px #005A9C solid; } 71 | 72 | .example 73 | { 74 | background-color: #CC9; 75 | } 76 | 77 | div.example, ul.example, p.example, ol.example 78 | { 79 | width: 80%; 80 | border: thin black solid; 81 | } 82 | 83 | @media print { 84 | .noprint { display: none } 85 | } 86 | 87 | .todo { 88 | background-color:#FFC; 89 | } -------------------------------------------------------------------------------- /draft-working-group-charter/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | W3C Solid Working Group Charter DRAFT-BR-2023-01-23 7 | 8 | 9 | 10 | 11 | 76 | 77 | 78 | 79 | 97 | 98 | 99 |
100 |

Solid Working Group Charter

101 | 102 |

103 | Cloud services in use on the Web today (2023) often require users to store their data and place control over that data at a third-party cloud provider. Solid adds to existing Web standards to enable user control: to realise a space where individuals can maintain their autonomy, control their data and privacy, and choose applications and services to fulfil their needs. Solid defines the notion of Pods, in which users place their own data and control access to that data, and a suite of interoperable protocols for managing Pods, applications that use pods, and interactions with existing protocols for authentication. 104 | 105 | Solid presents several advantages over more traditional architectures for data use by Web services today, including: 106 |

107 | 108 | 121 | 122 |

123 | W3C Members that would like to learn more about the motivations that led to this work may find the About Solid page useful. The Solid project consists of a draft specification and a suite of implementations, tools, and libraries for developers. 124 |

125 | 126 |

127 | The mission of the Solid Working Group (LINK TBD) is to standardize the Solid Protocol and its use of associated data interoperability and authentication schemes. This effort will culminate in open standards that can be used by developers of servers and applications to continue to build a rich ecosystem that returns control of data back to users. 128 |

129 | 130 |
131 |

132 | Join the Solid Working Group (LINK TBD). 133 |

134 |
135 | 136 |
137 | 138 | 139 | 142 | 145 | 146 | 147 | 150 | 153 | 154 | 155 | 156 | 159 | 164 | 165 | 166 | 169 | 172 | 173 | 174 | 177 | 185 | 186 |
140 | Start date 141 | 143 | DD Month YYYY 144 |
148 | End date 149 | 151 | DD Month YYYY 152 |
157 | Chairs 158 | 160 | Ruben Verborgh (imec)
161 | Justin Bingham (Janeiro Digital)
162 | Aaron Coburn (Inrupt) 163 |
167 | Team Contact 168 | 170 | Pierre-Antoine Champin (0.1 FTE) 171 |
175 | Meeting Schedule 176 | 178 | Teleconferences: 1-hour calls will be held bi-weekly 179 |
180 | Face-to-face: we will meet 181 | during the W3C's annual Technical Plenary week; additional face-to-face 182 | meetings may be scheduled by consent of the participants, usually no 183 | more than 3 per year. 184 |
187 |
188 | 189 |
190 |

Scope

191 | 192 |

193 | The design approach for the Solid specification will continue substantial efforts undertaken previously in the Solid community to specify a set of interoperable protocol standards for enabling the use and development of Solid Pods and applications across a wide range of use cases. 194 |

195 | 196 |

197 | The Working Group will: 198 |

199 |
    200 |
  1. 201 | Define a core protocol specification for the secure and efficient operation of Solid servers and the behavior of clients interacting with those servers. 202 |
    2. 203 |
  2. 204 | Recommend a data and protocol model for interoperability between multiple applications built upon Solid. 205 |
    3. 206 |
  3. 207 | Recommend a set of practices needed for data security for Solid Pods, and for both server and client software, including use of appropriate authentication, authorization, verification, identity, and other standards, integrating existing outside efforts. 208 |
    4. 209 |
  4. 210 | Recommend a set of protocol behaviors and best practices for the use in Solid of the OpenID Connect (OIDC) / Federation identity layer on top of the OAuth 2.0 protocol. 211 |
    5. 212 |
  5. 213 | Recommend a set of protocol behaviors and best practices to request and grant access to data stored in Solid Pods. 214 |
    6. 215 |
  6. 216 | Define a protocol for state synchronization regarding changes to resources in Solid pods. 217 |
    7. 218 |
219 | 220 |
221 |

Out of Scope

222 |

223 | The following features and topics are out of scope and will not be addressed by this Working Group. 224 |

225 | 226 |
    227 |
  • 228 | Definition of identity mechanisms such as WebID and DID 229 |
    • 230 |
  • 231 | Definition of linked data formats 232 |
    • 233 |
234 |
235 | 236 |
237 |

Success Criteria

238 |

239 | In order to advance to the status of 240 | Proposed Recommendation, each specification will fulfill the 241 | implementation experience required by the W3C Process as follows: 242 |

243 | 244 |
    245 |
  • 246 | The Working Group will seek evidence of independent interoperable uses of the Solid protocol from at least two independent implementations of each feature defined in the specification. 247 |
    • 248 |
  • 249 | The group will add a section detailing any known security or privacy implications for implementers, Web authors, and end users. 250 |
    • 251 |
  • 252 | The group will maintain and advance a test suite (LINK TBD), which, among other goals, will enable interoperability testing. 253 |
    • 254 |
255 |
256 |
257 | 258 |
259 |

260 | Deliverables 261 |

262 |

263 | More detailed milestones and updated publication schedules are available on the 264 | group publication status page (LINK TBD). 265 |

266 | 267 |
268 |

269 | Normative Specifications 270 |

271 |

272 | The Solid Working Group will deliver the following W3C normative specifications: 273 |

274 |
275 |
Solid Protocol v1.0
276 |
277 |

278 | The Solid Protocol specification aims to provide applications with secure and permissioned access to externally stored data in an interoperable way. An overarching design goal of the Solid ecosystem is to be evolvable and to provide fundamental affordances for decentralised Web applications for information exchange in a way that is secure and privacy respecting. In this environment, actors allocate identifiers for their content, shape and store data where they have access to, set access control policies, and use preferred applications and services to achieve them. 279 |

280 |

281 | When possible, the Solid Protocol will evolve while maintaining a high degree of compatibility with existing implementations, of both servers and clients, and with features from prior versions. If incompatible changes have to be made, then they will be done by introducing a stage where both old and new protocols are supported, to allow the implementors to upgrade their systems in a managed way. 282 |

283 |

284 | The Solid specification may include protocol details for integration with the following: 285 |

    286 |
  1. 287 | OpenID Connect 288 |
    2. 289 |
  2. 290 | Access grants using W3C Verifiable Credentials 291 |
    3. 292 |
  3. 293 | Identity mechanisms such as WebID and DID 294 |
    4. 295 |
  4. 296 | Notifications about resource changes 297 |
    5. 298 |
  5. 299 | Authorization mechanisms such as Web Access Control and Access Control Policy 300 |
    6. 301 |

    302 |
303 |
304 | 305 |

306 | Note that the WG may decide, based on editorial and readability considerations, to spin off sections into separate Recommendations track specifications. 307 |

308 |

309 | All specifications, regardless of their progress along the W3C process line from Working Draft to Recommendation, will be given a version number, such as 0.9, which will be incremented like from 0.9 to 0.10 for minor changes. A major version increment like 2.2 to 3.0 will be used if there is an incompatible change in the protocol. The required versions of each dependency will be given in each spec. 310 |

311 |
312 | 313 |
314 |

315 | Other Deliverables 316 |

317 |

318 | Other non-normative documents may be created such as: 319 |

320 |
321 |
Test Suite and Implementation Report
322 |
323 |

324 | The Working Group will develop a test suite and implementation report to test and document conformance levels achieved by implementors. 325 |

326 |
327 |
328 |
329 | 330 |
331 |

Timeline (TBD)

332 | 333 | 334 | 335 | 336 | 339 | 340 | 341 | 342 | 343 | 344 | 347 | 350 | 353 | 356 | 357 | 358 | 361 | 364 | 365 | 366 |
337 | Note: The group will document significant changes from this initial schedule on the group home page. 338 |
Specification 345 | FPWD 346 | 348 | CR 349 | 351 | PR 352 | 354 | Rec 355 |
359 | Solid Protocol 360 | 362 | Month YYYY 363 |
367 | 368 |
369 |
370 | 371 | 372 |
373 |

Coordination

374 |

375 | For all specifications, this Working Group will seek horizontal review 376 | for accessibility, internationalization, performance, privacy, and 377 | 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 the FPWD and at least 3 months before the CR, and should be issued when major changes occur in a specification. 378 |

379 | 380 |

381 | Additional technical coordination with the following Groups will be made, per the W3C Process Document: 382 |

383 | 384 |
385 |

W3C Groups

386 | 387 |
388 |
389 | Verifiable Credentials Working Group 390 |
391 |
392 | Coordination on mechanisms for granting access to resources. 393 |
394 |
395 | DID Working Group 396 |
397 |
398 | Coordination on mechanisms for decentralized identifier use in Solid. 399 |
400 |
401 | Credentials Community Group 402 |
403 |
404 | Coordination on other specifications related to Decentralized Identifiers. 405 |
406 |
407 | JSON-LD Working Group 408 |
409 |
410 | Coordination to ensure that the JSON-LD syntax meets the Solid Working Group's needs. 411 |
412 |
413 | Web Authentication Working Group 414 |
415 |
416 | Coordination to ensure that Web Authentication primitives align with Solid principles and aims. 417 |
418 |
419 | 420 |
421 | 422 | 434 |
435 | 436 |
437 |

438 | Participation 439 |

440 |

441 | To be successful, this Working Group is expected to have 442 | 6 or more active participants for its duration, including 443 | representatives from the key implementors of this specification, and 444 | active Editors and Test Leads for each specification. The Chairs, 445 | specification Editors, and Test Leads are expected to contribute half of 446 | a working day per week towards the Working Group. There is no minimum 447 | requirement for other Participants. 448 |

449 |

450 | The group encourages questions, comments and issues on 451 | its public mailing lists and document repositories, as described in Communication. 452 |

453 |

454 | W3C Members are invited to join this Working Group. Individuals who wish to participate as Invited Experts (i.e., they do not represent a W3C Member) should refer to the policy for approval of Invited Experts. 455 | The group also welcomes non-Members to contribute technical submissions 456 | for consideration upon their agreement to the terms of the W3C Patent Policy. 457 |

458 |
459 | 460 |
461 |

462 | Communication 463 |

464 |

465 | Technical discussions for this Working Group are conducted in public: 466 | the meeting minutes from teleconference and face-to-face meetings will 467 | be archived for public review, and technical discussions and issue 468 | tracking will be conducted in a manner that can be both read and written 469 | to by the general public. Working Drafts and Editor's Drafts of 470 | specifications will be developed on a public repository, and may permit 471 | direct public contribution requests. The meetings themselves are not 472 | open to public participation, however. 473 |

474 |

475 | Information about the group (including details about 476 | deliverables, issues, actions, status, participants, and meetings) will 477 | be available from the Solid Working Group home page (LINK TBD). 478 |

479 |

480 | Most Working Group 481 | teleconferences will focus on discussion of particular specifications, 482 | and will be conducted on an as-needed basis. 483 |

484 |

485 | This group primarily conducts its technical work on the public mailing list public-solid-wg@w3.org (LINK TBD) ( archive (LINK TBD)) or on GitHub issues (LINK TBD) 486 | (and specification-specific GitHub repositories and issue trackers). 487 | The public is invited to review, discuss and contribute to this work. 488 |

489 |

490 | The group will publish minutes for each teleconference at https://github.com/w3c/solid-wg/Meeting/Minutes/ (LINK TBD). 491 |

492 |
493 | 494 |
495 |

496 | Decision Policy 497 |

498 |

499 | This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). 500 | Typically, an editor or other participant makes an initial proposal, 501 | which is then refined in discussion with members of the group and other 502 | reviewers, and consensus emerges with little formal voting being 503 | required. 504 |

505 |

506 | However, if a decision is necessary for timely progress, 507 | but consensus is not achieved after careful consideration of the range 508 | of views presented, the Chairs may call for a group vote, and record a 509 | decision along with any objections. 510 |

511 |

512 | To afford asynchronous decisions and organizational 513 | deliberation, any resolution (including publication decisions) taken in a 514 | face-to-face meeting or teleconference will be considered provisional. 515 |

516 |

517 | A call for consensus (CfC) will be issued for all 518 | resolutions (for example, via email and/or web-based survey), with a 519 | response period from one week to 10 working days, depending on the 520 | chair's evaluation of the group consensus on the issue. 521 |

522 |

523 | If no objections are raised on the mailing list by the 524 | end of the response period, the resolution will be considered to have 525 | consensus as a resolution of the Working Group. 526 |

527 |

528 | All decisions made by the group should be considered 529 | resolved unless and until new information becomes available, or unless 530 | reopened at the discretion of the Chairs or the Director. 531 |

532 |

533 | This charter is written in accordance with the W3C Process Document (Section 3.4, Votes), and includes no voting procedures beyond what the Process Document requires. 534 |

535 |
536 | 537 |
538 |

539 | Patent Policy 540 |

541 |

542 | This Working Group operates under the W3C Patent 543 | Policy (Version of 15 September 2020). To 544 | promote the widest adoption of Web standards, W3C seeks to issue 545 | Recommendations that can be implemented, according to this policy, on a 546 | Royalty-Free basis. 547 |

548 |

549 | For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation. 550 |

551 |
552 | 553 |
554 |

Licensing

555 |

556 | This Working Group will use the W3C Software and Document license for all its deliverables. 557 |

558 |
559 | 560 |
561 |

562 | About this Charter 563 |

564 |

565 | This charter has been created according to section 5.2 of the Process Document. 566 | In the event of a conflict between this document or the provisions of 567 | any charter and the W3C Process, the W3C Process shall take precedence. 568 |

569 | 570 |
571 |

572 | Charter History 573 |

574 | 575 |

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3):

576 | 577 | 578 | 579 | 580 | 581 | 582 | 583 | 584 | 585 | 586 | 587 | 588 | 589 | 590 | 591 | 592 |
Charter Period Start Date End Date Changes
Initial Charter Month YYYY Month YYYY none
593 |
594 |
595 |
596 | 597 |
598 | 599 | 608 | 609 | -------------------------------------------------------------------------------- /draft-working-group-charter/pubrules-style.css: -------------------------------------------------------------------------------- 1 | @import url("http://www.w3.org/StyleSheets/base.css"); 2 | 3 | /* Copyright 1997-2005 W3C (MIT, ERCIM, Keio). All Rights Reserved. 4 | The following software licensing rules apply: 5 | http://www.w3.org/Consortium/Legal/copyright-software */ 6 | 7 | /* $Id: pubrules-style.css,v 1.1 2018/01/25 15:52:23 plehegar Exp $ */ 8 | 9 | body { 10 | margin: 2em 1em 2em 70px; 11 | font-family: sans-serif; 12 | color: black; 13 | background-color: white; 14 | background-position: top left; 15 | background-attachment: fixed; 16 | background-repeat: no-repeat; 17 | } 18 | 19 | h1, h2, h3, h4, h5 { 20 | text-align: left; 21 | font-family: sans-serif; 22 | font-weight: normal; 23 | color: #005a9c; 24 | margin-left: 0 25 | } 26 | 27 | h4, h5, blockquote { margin-left: 1em } 28 | 29 | div.head p { margin-left: 0 } 30 | 31 | .first { margin: 3em 4em 2em 3em} 32 | 33 | div.head img { 34 | color: white; 35 | border: none; 36 | float:left; 37 | padding-right: 1em; 38 | padding-bottom: 1em; 39 | margin-left: 0 40 | } 41 | 42 | p { clear: left } 43 | 44 | /*p, ul, ol, blockquote, dl { margin-left: 2em }*/ 45 | 46 | th { text-align: left } 47 | 48 | .rfc2119 { 49 | text-transform: lowercase; 50 | font-weight: bold 51 | } 52 | 53 | /* Navigation styles from Eric Meyer */ 54 | /* 55 | http://www.complexspiral.com/events/archive/2003/seybold/cssnav.html 56 | */ 57 | 58 | /* Shared */ 59 | li.label { 60 | list-style: none; 61 | margin: 0; 62 | padding: .15em 0 .15em .5em; 63 | border-top: 1px solid gray; 64 | text-align: left; 65 | color: white; 66 | background: #0050B2; 67 | font-weight: bold; 68 | } 69 | 70 | /* highlighting and border effects */ 71 | #navbar {float:right} 72 | #navbar {padding: 0 1px 2em 1em; margin: 0; 73 | font: bold 10px sans-serif; 74 | background: white; width: 13em;} 75 | #navbar li {list-style: none; margin: 0; border-top: 1px solid gray; 76 | text-align: left;} 77 | #navbar li#current {list-style: none; margin: 0; border-top: 1px solid gray; 78 | text-align: left; background: #CCD; color: black; padding: 0.25em 0.5em 0.25em 0.75em; 79 | border-left: 1em solid #AAB; text-decoration: none;} 80 | #navbar li a {display: block; padding: 0.25em 0.5em 0.25em 0.75em; 81 | border-left: 1em solid #AAB; text-decoration: none;} 82 | /*#navbar li a:link {color: #448; }*/ 83 | #navbar li a:visited {color: #667; } 84 | #navbar li a:hover {border-color: #FE3; color: #FFF; background: #332;} 85 | 86 | /* Same for class version */ 87 | 88 | .navbar {float:right} 89 | .navbar {padding: 0 1px 2em 1em; margin: 0; 90 | font: bold 10px sans-serif; 91 | background: white; width: 13em;} 92 | .navbar li {list-style: none; margin: 0; border-top: 1px solid gray; 93 | text-align: left;} 94 | .navbar li#current {list-style: none; margin: 0; border-top: 1px solid gray; 95 | text-align: left; background: #CCD; color: black; padding: 0.25em 0.5em 0.25em 0.75em; 96 | border-left: 1em solid #AAB; text-decoration: none;} 97 | .navbar li a {display: block; padding: 0.25em 0.5em 0.25em 0.75em; 98 | border-left: 1em solid #AAB; text-decoration: none;} 99 | /*.navbar li a:link {color: #448; }*/ 100 | .navbar li a:visited {color: #667; } 101 | .navbar li a:hover {border-color: #FE3; color: #FFF; background: #332;} 102 | 103 | /* tabbed styles */ 104 | #navigation {padding: 3px 0; margin: 0; 105 | border-bottom: 1px solid #778; 106 | font: bold 10px sans-serif;} 107 | #navigation li {list-style: none; margin: 0; 108 | display: inline; line-height: 250%} 109 | #navigation li a {padding: 3px 0.5em; margin-left: 3px; 110 | border: 1px solid #778; border-bottom: none; 111 | background: #DDE; 112 | text-decoration: none;} 113 | #navigation li a:link {color: #448; } 114 | #navigation li a:visited {color: #667; } 115 | #navigation li a:hover {color: #000; background: #AAE; 116 | border-color: #227;} 117 | 118 | /* Same thing for class navigation */ 119 | .navigation {padding: 3px 0; margin: 0; 120 | border-bottom: 1px solid #778; 121 | font: bold 10px sans-serif; } 122 | .navigation li {list-style: none; margin: 0; 123 | display: inline; line-height: 250%} 124 | .navigation li a {padding: 3px 0.5em; margin-left: 3px; 125 | border: 1px solid #778; border-bottom: none; 126 | background: #DDE; 127 | text-decoration: none;} 128 | .navigation li a:link {color: #448; } 129 | .navigation li a:visited {color: #667; } 130 | .navigation li a:hover {color: #000; background: #AAE; 131 | border-color: #227;} 132 | 133 | 134 | /* "current tab" style */ 135 | #navigation li a#current {background: white; border-bottom: 1px solid white;} 136 | /* Same thing for class navigation */ 137 | .navigation li a#current {background: white; border-bottom: 1px solid white;} 138 | 139 | -------------------------------------------------------------------------------- /draft-working-group-charter/w3c_home.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | -------------------------------------------------------------------------------- /draft-working-group-charter/w3cdoc.css: -------------------------------------------------------------------------------- 1 | a:link img, a:visited img { 2 | border-style: none 3 | } 4 | 5 | html{ 6 | background-color: #fff; 7 | color: #000; 8 | margin:0; 9 | border:0;} 10 | 11 | body 12 | { 13 | background-color: #fff; 14 | padding: 0em 2em; 15 | font-family: "Gill Sans"; 16 | } 17 | 18 | h4, h5, h6 {border: none;} 19 | body.team 20 | { 21 | margin:0; 22 | border-right: 30px solid #FFEEC2; 23 | border-left: 30px solid #FFEEC2;} 24 | 25 | body.team:before {content:"Team confidential"; 26 | font-size: 2em; 27 | color: #F00; 28 | padding: 5px; 29 | font-weight: bold;} 30 | 31 | body.ab 32 | { 33 | margin:0; 34 | border-right: 30px solid #E2EDFE; ; 35 | border-left: 30px solid #E2EDFE;;} 36 | 37 | body.ab:before {content:"AB+Team confidential"; 38 | font-size: 2em; 39 | color: #F00; 40 | padding: 5px; 41 | font-weight: bold;} 42 | 43 | #content { background-color: #fff;} 44 | /*quotes*/ 45 | blockquote 46 | { 47 | background: #c8e3ea; 48 | padding: 0.5em; 49 | border-left: #999; 50 | border-width: 0 0 0 1px; 51 | border-style: none none none solid; 52 | font-family: "Gill Sans"; 53 | font-style: italic; 54 | } 55 | q 56 | { 57 | background: #c8e3ea; 58 | font-family: "Gill Sans"; 59 | font-style: italic; 60 | } 61 | blockquote:after { 62 | display: block; 63 | content: attr(cite); 64 | text-align: right; 65 | font-size: 0.7em; 66 | } 67 | 68 | blockquote cite.title, 69 | blockquote cite.author { 70 | font-style: italic; 71 | font-size: 0.8em 72 | } 73 | blockquote cite.title:before { 74 | content: "-- "; 75 | } 76 | 77 | /*PRE style*/ 78 | pre 79 | { 80 | padding: 0.5em; 81 | border-color: #c8e3ea; 82 | border-width: 1px 1px 1px 3px; 83 | border-style: solid; 84 | font-family: "Courier", fixed; 85 | } 86 | 87 | /*From http://www.w3.org/2005/09/table.css*/ 88 | table 89 | { 90 | border-collapse: collapse; 91 | margin: 1em auto; 92 | } 93 | 94 | table caption 95 | { 96 | margin-left: auto; 97 | margin-right: auto; 98 | } 99 | 100 | table, tr, th, td { border: 1px solid black; } 101 | th, td { padding: 5px 1em; } 102 | 103 | th 104 | { 105 | background: #005a9c; 106 | color: #fff; 107 | } 108 | 109 | th a:link { 110 | color: #fff; 111 | } 112 | 113 | th a:visited { 114 | color: #aaa; 115 | } 116 | 117 | #Icons { float: right; } 118 | 119 | #footer 120 | { 121 | border-color: #333; 122 | border-width: 1px 0 0 0; 123 | border-style: solid none none none; 124 | clear: both; 125 | font-size: 0.9em; 126 | } 127 | 128 | /* Stolen from /Stylesheets/activities.css */ 129 | ul#Navigate { font-size: 0.86em; } 130 | #Icons img { vertical-align: top; } 131 | .trail { vertical-align: bottom; } 132 | 133 | .boldblack 134 | { 135 | font-weight: bold !important; 136 | background: transparent; 137 | color: #000 !important; 138 | } 139 | 140 | /* right column */ 141 | #Contents 142 | { 143 | float: left; 144 | width: 70%; 145 | margin: 0 1% 1em 4%; 146 | } 147 | 148 | h1, h2, h3, h4, h5, h6 149 | { 150 | margin-bottom: 0; 151 | padding-bottom: 0.15em; 152 | border-bottom: 1px solid #ccc; 153 | background: transparent; 154 | color: #005a9c; 155 | font-weight: normal; 156 | } 157 | 158 | h1 159 | { 160 | margin-top: 1em; 161 | margin-bottom: 0; 162 | padding-bottom: 0.15em; 163 | border-bottom: none; 164 | background: transparent; 165 | color: #000; 166 | } 167 | 168 | p.firstelement, table, address { margin-top: 0.7em; } 169 | 170 | /* left column */ 171 | ul#Navigate, ul.nav 172 | { 173 | margin: 0; 174 | padding: 0.2em 0 0 0; 175 | } 176 | 177 | ul#Navigate 178 | { 179 | float: left; 180 | width: 13em; 181 | margin: 1em 0 0 0.2em; 182 | border-right: 1px solid gray; 183 | background: #c8e3ea; 184 | color: #000; 185 | text-indent: 2px; 186 | } 187 | 188 | ul#Navigate li, ul.nav li 189 | { 190 | padding: 0.2em 0 0.2em 0.3em; 191 | list-style: none; 192 | font-weight: normal; 193 | } 194 | 195 | ul.nav li { border-top: 1px solid gray; } 196 | 197 | ul#Navigate a, ul.nav li a 198 | { 199 | padding-right: 0.1em; 200 | background: transparent; 201 | color: #000; 202 | text-decoration: none; 203 | } 204 | 205 | ul#Navigate li.navcurrent, ul.nav li.navcurrent 206 | { 207 | list-style: disc; 208 | background: #fff; 209 | color: #000; 210 | } 211 | 212 | ul#Navigate li a:hover, .nav li a:hover, 213 | ul#Navigate li a:focus, .nav li a:focus 214 | { 215 | background: transparent; 216 | color: #00e; 217 | text-decoration: underline; 218 | } 219 | 220 | /* print */ 221 | 222 | @media print 223 | { 224 | body, html { font-family: sans-serif; } 225 | 226 | h1, h2, h3, h4, h5, h6 227 | { 228 | page-break-after: avoid; 229 | page-break-inside: avoid; 230 | } 231 | 232 | blockquote, pre, table { page-break-inside: avoid; } 233 | ul, ol, dl { page-break-before: avoid; } 234 | .whiteout, .trail, ul#Navigate, p#Validate { display: none; } 235 | 236 | div#Contents 237 | { 238 | float: none; 239 | width: 100%; 240 | } 241 | } 242 | 243 | .whiteout, .whiteout a:link, .whiteout a:visited 244 | { 245 | background: #fff; 246 | color: #fff; 247 | } 248 | 249 | .whiteout a:hover, .whiteout a:focus 250 | { 251 | background: #fff; 252 | color: #00e; 253 | } 254 | 255 | .whiteout a:active 256 | { 257 | background: #fff; 258 | color: #f00; 259 | } 260 | 261 | div.whiteout 262 | { 263 | margin: -10px 0 0 0; 264 | padding: 0; 265 | } 266 | 267 | /*#status { 268 | padding: .5em 2em; 269 | background-color: #FCC; 270 | margin: 0 auto;}*/ -------------------------------------------------------------------------------- /editors.md: -------------------------------------------------------------------------------- 1 | # Solid Editors 2 | 3 | Below is a listing of the Solid Editorial Team and their respective assignments. See [Reviewing Proposals](README.md#reviewing-proposals.md) for an explanation of how the editorial process is used to review and accept changes to Solid Specifications, the Solid Roadmap, and Supporting Documentation. 4 | 5 | ## Editorial Team 6 | 7 | | Name | WebID | 8 | | --------- | ---------- | 9 | | [Tim Berners-Lee](https://github.com/timbl) | [WebID](https://www.w3.org/People/Berners-Lee/card#i) | 10 | | [Justin Bingham](https://github.com/justinwb) | [WebID](https://justin.inrupt.net/profile/card#me) | 11 | | [Dmitri Zagidulin](https://github.com/dmitrizagidulin) | [WebID](https://dz.solid.community/profile/card#me) | 12 | | [Kjetil Kjernsmo](https://github.com/kjetilk) | [WebID](https://solid.kjernsmo.net/profile/card#me) | 13 | | [Sarven Capadisli](https://github.com/csarven) | [WebID](https://csarven.ca/#i) | 14 | 15 | ## Editorial Assignments 16 | 17 | Editorial assignments are broken into three sections; [Solid Specification](#solid-specification), [Solid Roadmap](#solid-roadmap), and [Supporting Documentation](#supporting-documentation). 18 | 19 | ### Solid Specification 20 | 21 | The Solid Specification covers a broad range of topics, from resource access and decentralized authentication to data portability and querying. Consequently, it requires a group of individuals with a wide range of skillsets to provide thorough editorial review of proposals to extend or alter the specification. 22 | 23 | Editorial assignments to the specification are by topic. A given editor may be assigned to one or more topics. Some topics may have dedicated primary documents, while other topics may occur throughout the specification. 24 | 25 | - [Resource Access](#resource-access) 26 | - [Identity](#identity) 27 | - [Authentication](#authentication) 28 | - [Authorization](#authorization) 29 | - [Events and Notifications](#events-and-notifications) 30 | - [Data Interoperability](#data-interoperability) 31 | - [Data Portability](#data-portability) 32 | - [Auditing](#auditing) 33 | - [Querying](#querying) 34 | - [Cryptography](#cryptography) 35 | - [Security](#security) 36 | 37 | #### Resource Access 38 | Pertaining to the access of resources in a data pod over a network via HTTP 39 | 40 | __Assigned Editors:__ Sarven Capadisli, Kjetil Kjernsmo 41 | __Primary Documents:__ [solid/specification/resource-access](https://github.com/solid/specification/blob/master/main/resource-access.bs) 42 | 43 | #### Identity 44 | Pertaining to mechanisms that universally identify people or applications. 45 | 46 | __Assigned Editors:__ Dmitri Zagidulin, Sarven Capadisli 47 | __Primary Documents:__ 48 | 49 | #### Authentication 50 | Pertaining to mechanisms that authenticate a person or application for the purposes of accessing resources in a data pod. 51 | __Assigned Editors:__ Justin Bingham, Dmitri Zagidulin 52 | __Primary Documents:__ [Solid-OIDC](https://solid.github.io/authentication-panel/solid-oidc/), [solid/specification/webid-tls](https://github.com/solid/specification/tree/master/webid-tls) 53 | 54 | #### Authorization 55 | Pertaining to mechanisms that control the access a given agent has to read or manipulate resources in a data pod. 56 | __Assigned Editors:__ Sarven Capadisli, Kjetil Kjernsmo, Dmitri Zagidulin 57 | __Primary Documents:__ [solid/specification/resource-access](https://github.com/solid/specification/blob/master/main/resource-access.bs), [solid/specification/wac](https://github.com/solid/specification/tree/master/wac), [solid/web-access-control-spec](https://github.com/solid/web-access-control-spec) 58 | 59 | #### Events and Notifications 60 | Pertaining to mechanisms that process and/or emit events between pods and agents, or other pods. 61 | __Assigned Editors:__ Sarven Capadisli, Dmitri Zagidulin 62 | __Primary Documents:__ 63 | 64 | #### Data Interoperability 65 | Pertaining to mechanisms that ensure disparate applications or agents can safely and seamlessly read and write the data they need. 66 | __Assigned Editors:__ Kjetil Kjernsmo, Justin Bingham, Sarven Capadisli 67 | __Primary Documents:__ 68 | 69 | #### Data Portability 70 | Pertaining to mechanisms that ensure the portability of data stored in a data pod such that it can be safely migrated between conformant Solid server implementations, as well as exported to other mediums. 71 | __Assigned Editors:__ Justin Bingham 72 | __Primary Documents:__ 73 | 74 | #### Data Models 75 | Pertaining to core vocabularies and data shapes essential to a working ecosystem of data pods and applications. 76 | __Assigned Editors:__ Kjetil Kjernsmo, Justin Bingham, Sarven Capadisli 77 | __Primary Documents:__ [solid/vocab](https://github.com/solid/vocab) 78 | 79 | #### Auditing 80 | Pertaining to the mechanisms through which access and manipulation events of resources in a data pod are recorded and accessible. 81 | __Assigned Editors:__ Dmitri Zagidulin 82 | __Primary Documents:__ 83 | 84 | #### Querying 85 | Pertaining to the mechanisms, such as SPARQL and TPF, through which a given agent can provide query parameters to a data pod and receive results satisfying the same. 86 | __Assigned Editors:__ Kjetil Kjernsmo 87 | __Primary Documents:__ 88 | 89 | #### Cryptography 90 | Pertaining to the mechanisms through which cryptographic techniques are employed to provide data privacy, data integrity, and verifiable information. 91 | __Assigned Editors:__ Dmitri Zagidulin 92 | __Primary Documents:__ 93 | 94 | #### Security 95 | Pertaining to mechanisms used and considerations taken when securing a data pod, a conformant server implementation, and/or the immediate ecosystem around them. 96 | __Assigned Editors:__ Justin Bingham, Sarven Capadisli, Dmitri Zagidulin 97 | __Primary Documents:__ [solid/specification/security](https://github.com/solid/specification/blob/master/main/security.bs) 98 | -------------------------------------------------------------------------------- /gitter-chat-overview.md: -------------------------------------------------------------------------------- 1 | Here is a record of all the Solid gitter channels and their aim. Anyone can submit an issue to update this file, and Administrators are responisble for responding and acting on these issues to keep this file up to date. 2 | # Standardisation 3 | Could include more channels for other the panels 4 | * [specifcation](https://gitter.im/solid/specification?source=orgpage) includes all panellists and editors 5 | * [security-cryptography-and-privacy](https://gitter.im/solid/cryptography-security-and-privacy#) 6 | * [app-authoriisation-panel](https://gitter.im/solid/app-authorization-panel?source=orgpage) 7 | * [authentication panel](https://gitter.im/solid/authentication-panel?source=orgpage) 8 | * [data-interoperability-panel](https://gitter.im/solid/data-interoperability-panel?source=orgpage) 9 | 10 | # Implementation 11 | Doubled up on https://forum.solidproject.org/categories 12 | * [pods](https://gitter.im/solid/pods?source=orgpage) 13 | * [app development](https://gitter.im/solid/app-development?source=orgpage) 14 | * [chat-app](https://gitter.im/solid/chat-app?source=orgpage) 15 | * [node-solid-server](https://gitter.im/solid/node-solid-server?source=orgpage) 16 | * [data browser](https://gitter.im/solid/data-browser?source=orgpage) 17 | 18 | ## Solid Events 19 | Doubled up on https://forum.solidproject.org/categories 20 | * [solid-events](https://gitter.im/solid/solid-events?source=orgpage) 21 | 22 | ## Test Suite 23 | * [test-suite](https://gitter.im/solid/test-suite?source=orgpage) 24 | 25 | ## Solidproject.org 26 | * [solidproject.org](https://gitter.im/solid/solidproject.org?source=orgpage) 27 | 28 | # Unknown Purpose 29 | The following chat channels don't have a clearly stated focus at the moment or have focuses that overlap with other gitter channels. If you use the chat channel regularly and know the focus submit a pull request to let others know. 30 | * [Solid Chat](https://gitter.im/solid/chat?source=orgpage) 31 | * [solid-spec](https://gitter.im/solid/solid-spec?source=orgpage) 32 | * [site-and-docs](https://gitter.im/solid/site-and-docs?source=orgpage) 33 | * [solid-git](https://gitter.im/solid/solid-git?source=orgpage) 34 | * [suggestions](https://gitter.im/solid/suggestions?source=orgpage) 35 | * [introductions](https://gitter.im/solid/introductions?source=orgpage) 36 | * [community](https://gitter.im/solid/community?source=orgpage) 37 | -------------------------------------------------------------------------------- /librarians.md: -------------------------------------------------------------------------------- 1 | 2 | | Name | GitHub Handle | 3 | | --------- | ---------- | 4 | | Joachim vH | @joachimvh | 5 | | Ruben T | @rubensworks | 6 | | Pieter Hayvaer | @pheyvaer | 7 | | --------- | @mielvds | 8 | 9 | 10 | 11 | 12 | 13 | -------------------------------------------------------------------------------- /notifications-panel-charter.md: -------------------------------------------------------------------------------- 1 |
2 | Document Status 3 |
4 |
Modified
5 |
2023-11-14
6 |
Reason
7 |
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.
8 |
9 |
10 | 11 | --- 12 | 13 | # Notifications Panel Charter 14 | 15 | The mission of the Notifications Panel as part of the W3C Solid Community Group is to extend or define technical protocols and vocabularies to facilitate notification exchange on the Open Web Platform. 16 | 17 | * Start date: 2021-09-13 18 | * End date: 2022-12-31 19 | * Charter extension: The charter extension history is documented in "About this charter". 20 | * Confidentiality: Proceedings are Public 21 | * Chair: [Sarven Capadisli](https://csarven.ca/#i) 22 | * Team Contact: Solid Editors 23 | * Usual Meeting Schedule: Teleconferences: Weekly, although the chair may call for topic-specific calls in addition when needed and may change working mode as work progresses. 24 | 25 | ## Goals 26 | 27 | The Notifications Panel will create technical reports that standardise protocols and vocabularies for exchanging information as notifications. This should allow Web application developers to embed and facilitate access to social communication on the Web. The panel will explore use cases and requirements pertaining to activities in the Solid ecosystem; identify how existing specifications, including their specialisations and extensions, can be reused; as well as develop new specifications. The work will be driven and refined by implementation experience. The panel will collaborate with other Solid panels and may take on or pass on challenges. 28 | 29 | There are a number of use cases that the work of this panel will enable, including but not limited to: 30 | 31 | * User control of personal data: Some users would like to have autonomous control over their own social data, and share their data selectively across various systems. 32 | * Activity subscriptions: Actors in the system may want information sent to them about particular data or when certain events or activities take place. 33 | * Resource Access: Access to resources or services to request permission (in order to perform operations). 34 | * Service Actions: Such as activate services, create resources, create/update/delete user accounts, migrate pods, archive pods, or delegate agents to perform tasks. 35 | 36 | 37 | ## Scope 38 | 39 | The panel within the framework of the W3C Solid CG and the Solid Project will determine the use cases that derive the requirements for the deliverables. Features that are not implemented due to time constraints can be put into a non-normative "roadmap" document for future work. The scope will include: 40 | 41 | * A transfer syntax for data such as activities should include at least the ability to describe the data using URIs in an extensible manner, time-stamping, and a serialization compatible with the RDF language. 42 | 43 | * A protocol for exchanging social data should include at least the ability to share notifications using the transfer syntax developed by the Notifications Panel or extend syntaxes such as Activity Streams 2.0. This protocol may allow the capture of new data, the verification of data using techniques such as as digital signatures, server to server interactions, and the use of groups with some form of access control or capabilities. 44 | 45 | * Documentation detailing upgrade paths for existing technical reports or notes, including, but not limited to, upgrading deprecated insecure WebSockets to secured WebSockets. 46 | 47 | Other components necessary for building federated/decentralized social Web systems are in scope but will not lead to a recommendation without re-chartering, and should be discussed in the Notifications Panel. 48 | 49 | ### Success Criteria 50 | 51 | In order to advance to technical report, the specification is expected to have two independent interoperable implementations of each feature defined in the specification. Independent implementations are developed by different parties and cannot share, reuse, or be derived from code of another qualifying implementation which is directly pertinent to the implementation of this specification. 52 | 53 | ## Deliverables 54 | 55 | ### Normative Deliverables 56 | 57 | The panel will deliver the following to fulfill its goals, subject to discussion in the Solid CG: 58 | 59 | * Notification Protocol 60 | * Notification Syntax 61 | 62 | Each of these technologies should not be tightly-coupled but can allow general purpose use. Each specification must contain a section detailing any known security and privacy implications for implementers, Web authors, and end users. The Notifications Panel will actively seek an open security and privacy review for every normative deliverable. 63 | 64 | ### Other Deliverables 65 | 66 | The panel will deliver other non-normative documents, such as the following: 67 | 68 | * A Use Cases and Requirements document defining how features in each specification relate to concrete use-cases. 69 | * Test Suites for normative deliverables. 70 | * Upgrade Notes 71 | 72 | The panel may also deliver the following: 73 | 74 | * Primer or Best Practice documents to support Web developers when designing Solid applications. 75 | 76 | ### Milestones 77 | 78 | The production of the deliverables depends upon the resources available, and will change as new information and implementation experience is reported to the group. The most up-to-date timeline is available from the Solid CG page. 79 | 80 | | Specification | ~FPWD | ~LC | ~CR | ~PR | ~Rec | 81 | |---------------|---------|---------|---------|---------|---------| 82 | | x | 2021-Q4 | 2022-Q1 | 2022-Q2 | 2022-Q3 | 2022-Q4 | 83 | 84 | Note: The Notifications Panel as part of the W3C Solid CG does not publish technical reports under the W3C Recommendation track. Thus, the milestones in the table above that are prefixed with "~" only communicate rough equivalence in maturity level of the technical reports according to section 6.2.1 of the W3C Process. 85 | 86 | ## Coordination 87 | 88 | Technical coordination with the following Groups may be required: 89 | 90 | ### W3C Groups 91 | 92 | * [Consent CG](https://www.w3.org/groups/cg/consent) 93 | * [Credentials CG](https://www.w3.org/groups/cg/credentials) 94 | * [JSON-LD WG](https://www.w3.org/groups/wg/json-ld) 95 | * [Privacy CG](https://www.w3.org/groups/cg/privacycg) 96 | * [RDF-DEV CG](https://www.w3.org/groups/cg/rdf-dev) 97 | * [Social Web Incubator CG](https://www.w3.org/groups/cg/socialcg) 98 | * [Web Applications WG](https://www.w3.org/groups/wg/webapps) 99 | 100 | Furthermore, the Notifications Panel expects to follow the following W3C Recommendations, Guidelines, and Notes, and, if necessary, to liaise with the communities behind them: 101 | 102 | * [Architecture of the World Wide Web, Volume I](https://www.w3.org/TR/webarch/) 103 | * [Internationalization Technical Reports and Notes](http://www.w3.org/International/publications) 104 | * [QA Framework: Specification Guidelines](http://www.w3.org/TR/qaframe-spec/) 105 | 106 | ### External Groups 107 | 108 | * TBD 109 | 110 | ## Participation 111 | 112 | Membership in the W3C Solid CG is required to participate in the Notifications Panel. All work and communication within the Solid CG is covered by the [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md) as well as the [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/). 113 | 114 | To be successful, the Notifications Panel is expected to have 10 or more active participants for its duration and to have the participation of industry leaders in fields relevant to the specifications it produces. The Chairs and specification Editors are expected to contribute one to two days per week towards the Panel. The Chair may call occasional meetings consistent with the W3C Process requirements for meetings. There is no minimum requirement for other Participants. 115 | 116 | The Notifications Panel will also allocate the necessary resources for building test suites for each specification. 117 | 118 | The group encourages questions and comments on its project repository, as described in Communication. 119 | 120 | ## Communication 121 | 122 | Most Notifications Panel Teleconferences will be conducted on an as-needed basis. Normally, at least one teleconference will be held per week. 123 | 124 | Most of the technical work of the panel will be done through: 125 | 126 | * Repository: https://github.com/solid/notifications-panel 127 | * Discussions: https://gitter.im/solid/notifications-panel 128 | 129 | Information about the panel (for example, details about deliverables, issues, actions, status, and participants) will be available from the Notifications Panel repository. 130 | 131 | ## Decision Policy 132 | 133 | As explained in the W3C Process Document (section 3.3), this group will seek to make decisions when there is consensus and with due process. The expectation is that 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, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation -- using, for example, chat channel or panel repository) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available. 134 | 135 | This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires. 136 | 137 | ## Licensing 138 | 139 | The panel will use the MIT license for all its deliverables. 140 | 141 | ## Patent Policy 142 | 143 | This W3C Solid Community Group operates under the W3C Community Contributor License Agreement (CLA). 144 | 145 | ## About this Charter 146 | 147 | This charter for the Notifications Panel has been created according to section 5.2 of the W3C 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. 148 | 149 | ### Charter History 150 | 151 | The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3): 152 | 153 | | Charter Period | Start Date | End Date | Changes | 154 | |-----------------|------------|------------|------------| 155 | | Initial Charter | 2019-08-23 | 2021-09-12 | | 156 | -------------------------------------------------------------------------------- /panels.md: -------------------------------------------------------------------------------- 1 | # Solid Panels 2 | 3 | Below is a listing of [Solid Panels](README.md#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. 4 | 5 | Anyone can create a Solid Panel by submitting a request to the Solid W3C community group mailing list, or by making a pull request directly to this document. 6 | 7 | This listing helps people find panels in which they may want to participate, and helps editors find panels to consult as part of the editorial process. 8 | 9 | ## Example Panel 10 | This is an example that people can use as a template for submitting their own panels. A description of the panel, including its focus and goal, should go here. 11 | 12 | ### Communication channels 13 | - Link to join mailing list goes here 14 | - Link to public chat goes here 15 | - Any other public communication link goes here 16 | 17 | ### Panelists 18 | - [Panelist Name](link to github profile) <[email@example.org](mailto:email@example.org)> (@github handle) 19 | - [Panelist Name](link to github profile) <[email@example.org](mailto:email@example.org)> (@github handle) 20 | 21 | ### Editorial Assignment 22 | Candidate Proposals to the Solid Specification produced by this panel are likely to be associated with the [Editorial Assignment Name](https://github.com/solid/process/blob/master/editors.md#insert-editorial-assignment-link), and will be principally reviewed by any editors assigned to it. 23 | 24 | ## Index of Panels 25 | 26 | * [Authorization](#authorization) 27 | * [Authentication](#authentication) 28 | * [Interoperability](#interoperability) 29 | * [Test-suite](#test-suite) 30 | * [Notifications](#notifications) 31 | 32 | All Panels can be reached on [public-solid@w3.org](https://lists.w3.org/Archives/Public/public-solid/) 33 | 34 | There is a weekly W3C Solid Community Group call to review all panels on Thursdays alternating between 1000CEST and 1600CEST on https://zoom.us/j/121552099. See [here](https://www.w3.org/community/solid/wiki/Meetings) to read the minutes of previous calls, find out the agenda and exact time of the next call, or to add an item to the next agenda. 35 | 36 | You can also read weekly updates of all panels on [This Week in Solid](https://github.com/solid/information/blob/master/weekly-updates/this-week-in-solid.md). 37 | 38 | ## Authorization 39 | How various agents and authorized to access resources. 40 | 41 | ### Communication channels 42 | - Wednesdays at 10AM Eastern at https://hangouts.google.com/call/vsPFdfBxsTgfHcjKbmcXAEEE 43 | - [app authorization repository](https://github.com/solid/authorization-and-access-control-panel/issues/) 44 | - [app authorization gitter channel](https://gitter.im/solid/app-authorization-panel) 45 | 46 | ### Panelists 47 | - [Dmitri Zagidulin](https://github.com/dmitrizagidulin) <[dzagidulin@gmail.com](mailto:dzagidulin@gmail.com)> (@dmitrizagidulin) 48 | - [Michael Thornburgh](https://github.com/zenomt) <[mthornbu@adobe.com](mailto:mthornbu@adobe.com)> (@zenomt) 49 | - [Justin Bingham](https://github.com/justinwb) <[justin.bingham@janeirodigital.com](mailto:justin.bingham@janeirodigital.com)> (@justinwb) 50 | - [Jackson Morgan](https://github.com/jaxoncreed) <[jacksonm@inrupt.com](mailto:jacksonm@inrupt.com)> (@jaxoncreed) 51 | - [Sarven Capadisli](https://github.com/csarven) <https://csarven.ca/#i> (@csarven) 52 | - [Henry Story](http://github.com/bblfish) <[henry.story@bblfish.net](mailto:henry.story@bblfish.net)> (@bblfish) 53 | - [Jamie Fiedler](https://github.com/jamiefiedler) <[j@jf.dev](mailto:j@jf.dev)> (@jamiefiedler) 54 | 55 | 56 | ### Editorial Assignment 57 | Candidate Proposals to the Solid Specification produced by this panel are likely to be associated with the [Authorization editorial topic](https://github.com/solid/process/blob/master/editors.md#authorization), and will be principally reviewed by any editors assigned to it. 58 | 59 | ## Authentication 60 | Discussion and specs relating to Authentication and Auth Delegation protocols, including: 61 | * [Solid-OIDC](https://github.com/solid/solid-oidc) auth delegation protocol 62 | * [WebID-TLS](http://www.w3.org/2005/Incubator/webid/spec/tls) auth delegation protocol 63 | * Username + password recommendations for local authentication 64 | * [WebAuthentication](https://www.w3.org/TR/webauthn/) (proposed future integration) 65 | * DID Authentication (proposed future integration) 66 | * HTTP Signatures (proposed future integration) 67 | 68 | ### Communication channels 69 | - Mondays at 10AM Eastern at https://meet.jit.si/solid-authentication 70 | - [dedicated forum thread](https://forum.solidproject.org/t/authentication-panel/2086) 71 | - [authentication panel repository](https://github.com/solid/authentication-panel) 72 | 73 | ### Panelists 74 | - [Dmitri Zagidulin](https://github.com/dmitrizagidulin) <[dzagidulin@gmail.com](mailto:dzagidulin@gmail.com)> (@dmitrizagidulin) 75 | - [Paul Worrall](https://github.com/pjworrall) <[paulw@inrupt.com](mailto:paulw@inrupt.com)> (@pjworrall) 76 | - [Michael Thornburgh](https://github.com/zenomt) <[mthornbu@adobe.com](mailto:mthornbu@adobe.com)> (@zenomt) 77 | - [Justin Bingham](https://github.com/justinwb) <[justin.bingham@janeirodigital.com](mailto:justin.bingham@janeirodigital.com)> (@justinwb) 78 | - [Jackson Morgan](https://github.com/jaxoncreed) <[jacksonm@inrupt.com](mailto:jacksonm@inrupt.com)> (@jaxoncreed) 79 | - [Aaron Coburn](https://github.com/acoburn) <[aaronc@inrupt.com](mailto:aaronc@inrupt.com)> (@acoburn) 80 | - [Matthias Evering](https://github.com/ewingson) <[me@evering.eu](mailto:me@evering.eu)> (@ewingson) 81 | - [Henry Story](http://github.com/bblfish) <[henry.story@bblfish.net](mailto:henry.story@bblfish.net)> (@bblfish) 82 | - [Jamie Fiedler](https://github.com/jamiefiedler) <[j@jf.dev](mailto:j@jf.dev)> (@jamiefiedler) 83 | 84 | 85 | ### Editorial Assignment 86 | Candidate Proposals to the Solid Specification produced by this panel are likely to be associated with the [Authentication editorial topic](https://github.com/solid/process/blob/master/editors.md#authentication), and will be principally reviewed by any editors assigned to it. 87 | 88 | ## Interoperability 89 | Ensuring the interoperability of data as it is read and written by different users and/or applications. Topics of discussion will include vocabularies, shapes, shape trees, and the mechanisms through which these work together to provide consistent and safe access and manipulation of data in a pod by different agents and/or users. 90 | 91 | ### Communication channels 92 | - [data-interoperability-repository](https://github.com/solid/data-interoperability-panel) 93 | 94 | ### Panelists 95 | - [Dmitri Zagidulin](https://github.com/dmitrizagidulin) <[dzagidulin@gmail.com](mailto:dzagidulin@gmail.com)> (@dmitrizagidulin) 96 | - [Justin Bingham](https://github.com/justinwb) <[justin.bingham@janeirodigital.com](mailto:justin.bingham@janeirodigital.com)> (@justinwb) 97 | - [Eric Prud'hommeaux](https://github.com/ericprud) <[eric@w3.org](mailto:eric@w3.org)> (@ericprud) 98 | - [Max Dor](https://github.com/maxidorius) <[max@dorius.io](mailto:max@dorius.io)> (@maxidorius) 99 | - [James Schoening](https://github.com/jimschoening) <[james.r.schoening.civ@mail.mil](mailto:james.r.schoening.civ@mail.mil)> (@jimschoening) 100 | - [Jose Emilio Labra Gayo](http://labra.weso.es) <[jelabra@gmail.com](mailto:jelabra@gmail.com)> (@labra) 101 | - [Kjetil Kjernsmo](https://github.com/orgs/solid/people/kjetilk) <[kjetil@inrupt.com](mailto:kjetil@inrupt.com)> (@kjetilk) 102 | - [Jason Reynolds](https://github.com/orgs/solid/people/JKReynolds) <[jason.reynolds@polarisalpha.com](mailto:jason.reynolds@polarisalpha.com)> (@JKReynolds) 103 | - [Simon Shapiro](https://github.com/SimonShapiro) <[simon.m.shapiro@gmail.com](mailto:simon.m.shapiro@gmail.com)> (@SimonShapiro) 104 | - [Sarven Capadisli](https://github.com/csarven) <https://csarven.ca/#i> (@csarven) 105 | - [Arne Hassel](http://github.com/megoth) <[arneh@inrupt.com](mailto:arneh@inrupt.com)> <@megoth_twitter> 106 | - [Aaron Coburn](https://github.com/acoburn) <[aaronc@inrupt.com](mailto:aaronc@inrupt.com)> (@acoburn) 107 | - [Jamie Fiedler](https://github.com/jamiefiedler) <[j@jf.dev](mailto:j@jf.dev)> (@jamiefiedler) 108 | - [Elf Pavlik](https://github.com/elf-pavlik) (@elf-pavlik) 109 | 110 | 111 | ### Editorial Assignment 112 | Candidate Proposals to the Solid Specification produced by this panel are likely to be associated with the [Data Interoperability and Portability editorial topic](https://github.com/solid/process/blob/master/editors.md#data-interoperability-and-portability), and will be principally reviewed by any editors assigned to it. 113 | 114 | ## Test Suite 115 | The panel will develop open source conformance testing software, author and review tests, release implementation reports, and provide feedback to technical report development. See [Charter]((https://github.com/solid/process/blob/main/test-suite-panel-charter.md) 116 | 117 | ### Communication channels 118 | * [test-suite-panel repository](https://github.com/solid/test-suite-panel) 119 | * [test-suite-panel discussion](https://gitter.im/solid/test-suite) 120 | 121 | ## Notifications 122 | Development of mechanisms to shape and exchange notifications. See [Charter](https://github.com/solid/process/blob/main/notifications-panel-charter.md). 123 | 124 | ### Communication channels 125 | * [notifications-panel repository](https://github.com/solid/notifications-panel) 126 | * [notifications-panel discussion](https://gitter.im/solid/notifications-panel) 127 | 128 | 129 | ### Editorial Assignment 130 | The test suite should never contradict the Solid specification. 131 | When implementations and specification disagree, the test suite can help bring them closer together, 132 | but should not itself act as a voice in the discussion. 133 | It should help pod server implementations comply with the specification. 134 | It should help pod server implementations be compatible with one another. 135 | It doesn't necessarily have to test every possible combination of situations as long as it is useful 136 | to pod server implementers, and the reports its produces are a reliable source of information. 137 | -------------------------------------------------------------------------------- /repo-overview.md: -------------------------------------------------------------------------------- 1 | # Solid GitHub Repository Overview 2 | 3 | The [Solid GitHub organisation](https://github.com/solid/) contains several repositories. This document aims to provide an overview of the aim of each of the repositories and who is actively maintaining each repository. 4 | 5 | If you have more information [submit an issue](https://github.com/solid/process/issues) and a Solid Administrator will make a decision on how to incorporate the issue into this file. 6 | 7 | The following describes the governance, administration, and communication via the website: 8 | 9 | | Activity | Associated Repositories | Individuals Currently Active | 10 | | ------------- | ------------- | ------------- | 11 | | Administration | [owner on Solid members](https://github.com/orgs/solid/people) | Solid Director, Solid Manager, Administrators | 12 | | Process | [Process](https://github.com/solid/process) | Solid Director, Solid Manager | 13 | | solidproject.org | [solidproject.org](https://github.com/solid/solidproject.org), [solid github io](https://github.com/solid/solid.github.io) | Creators | 14 | | Communication | [Communication](https://github.com/solid/communication) | Solid Director, Solid Manager | 15 | | Roadmap | [Roadmap](https://github.com/solid/roadmap) | Solid Director, Solid Manager | 16 | 17 | These are the key [respositories associated to the specification development](https://github.com/search?q=topic%3Aspecification+org%3Asolid&type=Repositories) which are tagged 'specification' and are managed by the [Editors](https://github.com/orgs/solid/teams/editors) with input from the [Panellists](https://github.com/orgs/solid/teams/panels) 18 | 19 | | Activity | Associated Repositories | Individuals Currently Active | 20 | | ------------- | ------------- | ------------- | 21 | | Latest Version of the Specification | [Specification](https://github.com/solid/specification) | Editors | 22 | | Specification Authoring | [authorization panel](https://github.com/solid/authorization-and-access-control-panel/issues/), [authentication panel](https://github.com/solid/authentication-panel), [interoperability panel](https://github.com/solid/interoperability-panel), | [Panellists](https://github.com/solid/process/blob/master/panels.md) | 23 | | Test Suite Development | [Test Suite](https://github.com/solid/test-suite) | Editors | 24 | 25 | ## Running Code 26 | 27 | There are several implementations of Solid in the Solid GitHub that can be found in [repositories tagged 'running-code'](https://github.com/search?q=topic%3Arunning-code+org%3Asolid&type=Repositories). IMEC and more specifically, [these team members](https://github.com/orgs/solid/teams/imec/members) are responsible for the [repositories listed here](https://github.com/orgs/solid/teams/imec/repositories). [These team members](https://github.com/orgs/solid/teams/other/members) are responsible for [these repositories](https://github.com/orgs/solid/teams/other/repositories). 28 | 29 | ## Archived 30 | 31 | There are over thirty [archived repositories](https://github.com/solid?q=&type=archived&language=) with information that is now covered by solidproject.org or a reference to currently inactive panels. 32 | -------------------------------------------------------------------------------- /solid-cg-charter.md: -------------------------------------------------------------------------------- 1 |
2 | Document Status 3 |
4 |
Modified
5 |
2023-11-14
6 |
Reason
7 |
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.
8 |
9 |
10 | 11 | --- 12 | 13 | # W3C Solid Community Group Charter 14 | 15 | * Created: 2023-07-04 16 | * Modified: 2023-09-06 17 | * Effective: 2023-09-01 18 | * Version: 1.0 19 | 20 | The aims of the [Solid project](https://solidproject.org/) are in line with those of the Web itself: empowerment towards "an equitable, informed and interconnected society" [[ethical-web-principles](https://www.w3.org/TR/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. 21 | 22 | The mission of the [Solid Community Group](https://www.w3.org/groups/cg/solid/) 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. 23 | 24 | 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](https://solidproject.org/ED/qa) initiative. 25 | 26 | As per W3C [structures for groups](https://www.w3.org/groups/) and [W3C Process](https://www.w3.org/Consortium/Process/), the Community Group will maintain its focus on [incubating](https://www.w3.org/Guide/incubation) technical reports, prototyping software, and testing implementations within the [Scope](#Scope) of the charter, with the aim of advancing mature works to the W3C Recommendation track in a Working Group. 27 | 28 | The Solid community with various stakeholders comes together under the umbrella of the [Solid Project](https://solidproject.org/), 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. 29 | 30 | ## Scope 31 | 32 | 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](https://www.w3.org/TR/webarch/). These topics include, but not limited to, the following: 33 | 34 | * Protocols for the storage, transmission and portability of data. 35 | * Authentication and authorization mechanisms. 36 | * Notifications. 37 | * Query interfaces. 38 | * (Meta)data models that can be used in storages, e.g., policies, data privacy and rights, provenance records and auditing, error messages. 39 | * Profile descriptions for social and software agents. 40 | * Data interoperability: sharing semantics of the content of resources, e.g., data shapes, data portability. 41 | * Service interoperability: sharing semantics on the discovery of actions and access to resources, e.g, web service descriptions, provisioning, portability. 42 | * User interface affordances: the display of data and services in a view. 43 | * Vocabularies providing the necessary semantics for the mechanisms defined within the scope of this group. 44 | * Signing messages. 45 | * Federation, e.g., message passing, trust, data cascading. 46 | * Evaluation tools (software programs or online services) that help determine implementation conformance. 47 | * Publishing test reports and communicating the level of adoption of technical reports. 48 | 49 | 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. 50 | 51 | 52 | ### Out of Scope 53 | 54 | In general, topics that are “out of scope” involve anything not directly related to the above. Some examples of these are listed here: 55 | 56 | * The relative merits of various economic, political, or sociological theories. 57 | * 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. 58 | * Community Group's Work Items that have transitioned to a deliverable of an active Working Group. 59 | 60 | 61 | ## Work Items 62 | 63 | The Community Group current work items are listed at [Solid Technical Reports](https://solidproject.org/TR/). 64 | 65 | 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. 66 | 67 | [The work item process is outlined here](https://github.com/solid/specification/blob/main/CONTRIBUTING.md#work-items). 68 | 69 | 70 | ## Coordination 71 | 72 | The group will make good faith efforts to include the following communities in the progress of our work. 73 | 74 | * [Autonomous Agents on the Web Community Group](https://www.w3.org/groups/cg/webagents) 75 | * [Credentials Community Group](https://www.w3.org/groups/cg/credentials) 76 | * [Data Protection Vocabularies and Controls Community Group](https://www.w3.org/groups/cg/dpvcg) 77 | * [Dataset Exchange Working Group](https://www.w3.org/groups/wg/dx/) 78 | * [Decentralized Identifier Working Group](https://www.w3.org/groups/wg/did) 79 | * [LDP Next Community Group](https://www.w3.org/groups/cg/ldpnext) 80 | * [Notation 3 (N3) Community Group](https://www.w3.org/groups/cg/n3-dev) 81 | * [ODRL Community Group](https://www.w3.org/groups/cg/odrl) 82 | * [RDF-DEV Community Group](https://www.w3.org/groups/cg/rdf-dev) 83 | * [RDF-star Working Group](https://www.w3.org/groups/wg/rdf-star) 84 | * [Social Web Incubator Community Group](https://www.w3.org/groups/cg/socialcg) 85 | * [Verifiable Credentials Working Group](https://www.w3.org/groups/wg/vc) 86 | * [WebID Community Group](https://www.w3.org/groups/cg/webid) 87 | * [Web Platform Incubator Community Group](https://www.w3.org/groups/cg/wicg) 88 | * [Web of Things Working Group](https://www.w3.org/groups/wg/wot) 89 | 90 | The group expects to follow the following W3C Recommendations, Guidelines, and Notes, and, if necessary, to liaise with the communities behind them: 91 | 92 | * [Architecture of the World Wide Web, Volume I](https://www.w3.org/TR/webarch/) 93 | * [Internationalization Technical Reports and Notes](http://www.w3.org/International/publications) 94 | * [QA Framework: Specification Guidelines](http://www.w3.org/TR/qaframe-spec/) 95 | * [W3C Web Platform Design Principles](https://www.w3.org/TR/design-principles/) 96 | 97 | 98 | ## Participation 99 | 100 | The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in [Communication](#Communication) 101 | 102 | The [Solid Technical Reports Contributing Guide](https://github.com/solid/specification/blob/main/CONTRIBUTING.md) is available to all participants of the group that would like to make substantive contributions. 103 | 104 | 105 | ## Communication 106 | 107 | 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. 108 | 109 | Most Solid Community Group teleconferences will focus on discussion of particular specifications and QA work, and will be conducted on an as-needed basis. 110 | 111 | This group primarily conducts its technical work through: 112 | * GitHub repositories, e.g., https://github.com/solid/specification 113 | * Teleconference: https://meet.jit.si/solid-cg 114 | * Ad-hoc discussions and coordination: https://matrix.to/#/#solid_specification:gitter.im 115 | 116 | The public mailing list public-solid@w3.org may be used for general discussions and announcements. 117 | 118 | 119 | ## Decision Policy 120 | 121 | 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. 122 | 123 | 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. 124 | 125 | This charter is written in accordance with the [W3C Process Document (Section 5.2.3, Deciding by Vote)](https://www.w3.org/Consortium/Process/#Votes) and includes no voting procedures beyond what the Process Document requires. 126 | 127 | 128 | ## License 129 | 130 | The group will use [W3C copyright licenses](https://www.w3.org/copyright/) for all its work items except any software code artifacts, for which the group will use the [MIT license](https://opensource.org/license/mit/). 131 | 132 | - Per W3C Process, all contributions to the group fall under the [W3C Community Contributor License Agreement](https://www.w3.org/community/about/process/cla/) (CLA). 133 | 134 | - 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](https://www.w3.org/community/about/process/final/) (FSA). 135 | 136 | 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](https://www.w3.org/copyright/document-license-2023/). 137 | 138 | - In accordance with the CLA, the group licenses all its software artifacts under the [W3C Software license](https://www.w3.org/copyright/software-license-2023/), but without the notification obligation. 139 | 140 | 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](https://www.w3.org/copyright/software-license-2023/), but without notification obligation; any W3C Authoritative Test Suite a Working Group publishes will fall under a [dual license](https://www.w3.org/copyright/test-suites-licenses/) combining the [W3C Test Suite License](https://www.w3.org/copyright/test-suite-license-2023/) and the [W3C's 3-clause BSD license](https://www.w3.org/copyright/3-clause-bsd-license-2008/). 141 | 142 | The group strongly encourages its participants, as well as other stakeholders in the Solid ecosystem, to use the [MIT license](https://opensource.org/license/mit/), or another [OSI approved license](https://opensource.org/license/), for any open source software conforming to Solid specifications. 143 | 144 | 145 | 146 | ## Community Group Process 147 | 148 | Anything in this charter that conflicts with requirements of the [Community and Business Group Process](http://www.w3.org/community/about/agreements/) is void. 149 | 150 | Unless otherwise stated, the Community Group will follow or aim to be compatible with the [W3C Process](https://www.w3.org/Consortium/Process/). 151 | 152 | ### Participation and Voting Rights 153 | 154 | 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. 155 | 156 | Any participant of the Community Group who has also accepted the [W3C Community Contributor License Agreement](https://www.w3.org/community/about/process/cla/) (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. 157 | 158 | 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. 159 | 160 | ### Chairs 161 | 162 | The [role of the Chair](https://www.w3.org/Guide/chair/role.html) is described in the [Art of Consensus](https://www.w3.org/Guide/). 163 | 164 | The Community Group participants appoints (and re-appoints) Chairs for the group. 165 | 166 | The chair and the W3C Team Contact of the group SHOULD NOT be the same individual. 167 | 168 | 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. 169 | 170 | 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. 171 | 172 | Chair nominees and elected chairs per term MUST have unique affiliations. 173 | 174 | An affiliation MAY submit one ballot that ranks candidates in their preferred order. 175 | 176 | #### Choosing a Chair 177 | 178 | * 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. 179 | * 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. 180 | * 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. 181 | * Reelection is restricted to two consecutive terms, with the possibility of being reelected after sitting out one election cycle. 182 | * 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. 183 | * 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. 184 | * 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. 185 | * 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. 186 | * 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. 187 | * 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. 188 | 189 | #### Removing a Chair 190 | 191 | * Chairs may be removed from their duties through a no-confidence vote. 192 | * 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. 193 | * 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. 194 | * The other chairs must acknowledge the call for no confidence within 7 days of all three participants declaring their support. 195 | * 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. 196 | * 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. 197 | * 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. 198 | * A Chair who has been removed may stand for re-election. 199 | * 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. 200 | 201 | ## Amendments to this Charter 202 | 203 | * 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. 204 | * 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. 205 | * A public vote for a new charter must be called by the chairs within two weeks of the principled objection. 206 | * 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. 207 | * The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter. 208 | * Changes to the Coordination does not constitute an amendment to the charter that requires a rechartering vote. 209 | 210 | -------------------------------------------------------------------------------- /solid-editors-tr-phases.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | Consensus 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | Drafting 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | UCR 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | Starting point:PatchDocumentJust discussion 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | Submit issue 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | Then, 193 | 194 | 195 | 196 | 197 | 198 | create PRif ideas are mature,well documented,known to the community 199 | 200 | 201 | 202 | 203 | 204 | discuss the idea 205 | 206 | 207 | 208 | 209 | 210 | submit if ideas exist in space with existing specs 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | Finished! 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 3 positive reviews 233 | 234 | 235 | 236 | 237 | 238 | If insufficient positive reviews 239 | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | Once Editor records consensus 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | Assessment 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | Rejection 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | To clarify 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | UC/R Approved 298 | 299 | 300 | 301 | 302 | 303 | 304 | 305 | 306 | 307 | 308 | 309 | 310 | 311 | 312 | Finding ispublished 313 | 314 | 315 | 316 | 317 | 318 | Uncertain Ecosystem Impact 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | -------------------------------------------------------------------------------- /solid-editors-tr-process.md: -------------------------------------------------------------------------------- 1 | 
2 | Document Status 3 |
4 |
Modified
5 |
2023-11-14
6 |
Reason
7 |
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.
8 |
9 |
10 | 11 | --- 12 | 13 | # Solid Editors’ Technical Report Development Process 14 | 15 | ## Introduction 16 | 17 | The present non-normative document outlines a process in which the [Solid Editors](https://github.com/orgs/solid/teams/editors) 18 | group (hereafter simply “Editors”) intends to operate as a governing 19 | body to improve the speed of Solid Technical Report Development. The 20 | group will operate on a monthly cycle, in which it will process issues 21 | that are already on the Solid roadmap and that have been reported to 22 | the relevant Github repositories. Initially, the scope is limited to 23 | the [specification](https://github.com/solid/specification) repository, 24 | but it is expected that the scope will be widened. 25 | 26 | Editors will recruit contributors, including authors and reviewers, 27 | from the community, in addition to performing some of these roles 28 | themselves as appropriate. Even if a certain phase has a single 29 | assignee, this assignee may be any member of the community, and other 30 | contributors are welcome to assist. 31 | 32 | The Editors will examine open issues on a monthly basis, triage and 33 | prioritize them based on feedback from the community and an overall 34 | understanding of the ecosystem, and categorise them into phases 35 | depending on the maturity of the discussion of the issue(s). The Solid 36 | Roadmap influences the issues selected but changing the roadmap is not 37 | in the scope of this process. 38 | 39 | 40 | ## Issue Phases 41 | 42 | Open issues may be in one of several phases, and each phase has a 43 | different purpose and dynamic. Sometimes, the consensus is already 44 | sufficiently clear to enter the drafting phase, in which case a formal text 45 | is drafted. In most cases, consensus has not yet been reached, so 46 | a consensus-building phase is required. It is not generally a good 47 | idea to rush into a drafting phase, as a formal text is harder to 48 | write than an informal text that is sufficient for reaching 49 | consensus. In some cases, consensus cannot be reached because the use 50 | cases and requirements are unclear, in which a formal Use Cases and 51 | Requirements (UCR) phase is needed before the consensus process can 52 | progress. Identifying the need for a UCR phase can happen 53 | before or during the consensus phase. Sometimes, the issue is unclear 54 | because there is insufficient implementation experience or doubt of 55 | the long-term scalability of the proposal, in which case an 56 | assessment phase is needed. 57 | 58 | This process does not replace the process for submitting and deciding 59 | upon issues; it mainly guides how and when Solid Editors will engage 60 | on certain issues and/or rally support for resolution within a given 61 | time frame. 62 | 63 | The phases described below are sorted by shortest path to completion. 64 | Mature issues may be ready to enter the drafting phase immediately, 65 | with a quick route to being finished. In other cases, an issue may 66 | arise during the consensus phase, or earlier, in the UCR phase. Thus, 67 | this process differs from a conventional software development process 68 | that usually starts with a UCR phase. The following figure describes 69 | this in more detail: 70 | 71 | ![Phases of the Solid Editors Process](solid-editors-tr-phases.svg) 72 | 73 | 74 | ### Description of the Phases 75 | 76 | For an issue to be considered by the Editors, it must have been 77 | submitted [according to the process](https://github.com/solid/process#drafting-proposals). 78 | For now, the Editors' scope will be limited to issues in the 79 | [specification repository](https://github.com/solid/specification). 80 | Individual issues are often part of a larger problem space or feature 81 | set; in such case, the Editors may decide to group them. 82 | 83 | #### Drafting Phase 84 | 85 | ##### Purpose 86 | 87 | Produce a GitHub Pull Request to incorporate a formal text into a 88 | specification. 89 | 90 | ##### Entry 91 | 92 | An issue can enter the drafting phase if either of the following is met: 93 | 94 | * A rough consensus has been recorded on an issue or a set of issues. 95 | * A Solid Editor has deemed that the prior experience on the issue, 96 | particularly by existing implementations, is sufficient for drafting 97 | to begin. 98 | 99 | 100 | ##### Exit 101 | 102 | * An issue exits the drafting phase successfully once it has passed 103 | the [review process](https://github.com/solid/process#reviewing-proposals). 104 | * If the draft is met with significant opposition, it can exit 105 | unsuccessfully through mechanisms detailed in 106 | [Actions if rough consensus cannot be reached](#actions-if-rough-consensus-cannot-be-reached). 107 | * Solid Editors can decide that a draft can exit successfully or 108 | unsuccessfully in the end-of-month meeting. 109 | 110 | ##### Assignee Role 111 | 112 | The assignee in the drafting phase is responsible for being the 113 | primary author of the draft. 114 | 115 | 116 | #### Consensus Phase 117 | 118 | ##### Purpose 119 | 120 | Lead the community to form a rough consensus to resolve an outstanding 121 | issue. 122 | 123 | ##### Entry 124 | 125 | * Solid Editors will decide to enter an issue into the consensus 126 | phase based on three factors: 127 | 1. How much discussion about the issue has already taken place 128 | among the community on GitHub 129 | 2. The Editors' overall estimation of the position of the issue 130 | in the dependency tree of the overall ecosystem 131 | 3. The commitment of resources made to its resolution by actors 132 | in the community 133 | 134 | ##### Exit 135 | 136 | * An issue may successfully exit the consensus phase after an Editor 137 | records a rough consensus by posting a summary of the consensus in 138 | an issue comment. If the consensus was reached in a discussion that 139 | happened outside of the issue comments (e.g., in a face to face 140 | meeting, a scheduled video chat), the Editor must record the forum 141 | where the final discussion was held, who was present, and when it 142 | was decided. 143 | * In some cases, consensus cannot be reached, in which case, 144 | the issue may have an unsuccessful exit through the mechanisms 145 | detailed in [Actions if rough consensus cannot be reached](#actions-if-rough-consensus-cannot-be-reached). 146 | 147 | ##### Assignee Role 148 | 149 | The assignee in the consensus phase is responsible for facilitating 150 | the discussion. This may include summarizing different viewpoints, 151 | seeking to identify contentious points that can be discussed in 152 | separate issues, opening such issues if appropriate, scheduling 153 | higher-bandwidth conversations, and recruiting reviewers, among 154 | other things. 155 | 156 | #### Use Cases and Requirements phase 157 | 158 | ##### Purpose 159 | 160 | Clarify expectations for how a certain feature will be used in 161 | practice. 162 | 163 | ##### Entry 164 | 165 | * Community members may start a standardization process by offering a 166 | UCR document. 167 | * If rough consensus hasn't been reached in a consensus phase, 168 | one of the actions that the Editors may take is to [exit the 169 | consensus phase and enter a UCR phase](#actions-if-rough-consensus-cannot-be-reached) 170 | for the issue. 171 | 172 | ##### Exit 173 | 174 | * Solid Editors will review suggested requirements and/or use cases 175 | and decide whether the issue can progress to the next phase. 176 | 177 | ##### Assignee Role 178 | 179 | The assignee in the UCR phase is responsible for compiling and writing 180 | requirements and use cases that are relevant to the issue. 181 | 182 | #### Assessment Phase 183 | 184 | ##### Purpose 185 | 186 | Clarify how a suggested feature can be implemented without 187 | compromising the overall quality of the ecosystem. 188 | 189 | ##### Entry 190 | 191 | * Editors will review the discussion of the consensus phase to see whether 192 | community members have voiced reservations that need further assessment. 193 | Editors will record a comment detailing any open question(s) needing to 194 | be investigated. 195 | 196 | ##### Exit 197 | 198 | * An issue exits the assessment phase when a comment is posted 199 | detailing the results of the investigation. 200 | 201 | ##### Assignee Role 202 | 203 | The assignee in the assessment phase is responsible for making an 204 | investigation into the question that has been posted, and writing the 205 | comment listing the investigation details. 206 | 207 | 208 | ## Actions if rough consensus cannot be reached 209 | 210 | * Assignee should attempt to convene a higher-bandwidth conversation, 211 | such as a scheduled video conference. 212 | * Editors should actively seek consensus on subissues, and see if 213 | consensus can be recorded on these and new issues opened for the 214 | subissues. 215 | * Editors should assess from whence disagreement has stemmed. 216 | * An issue may exit unsuccessfully and be moved back to the backlog 217 | if disagreement stems from, for instance, insufficient 218 | implementation experience or performance considerations. 219 | * If disagreements stem from a lack of clarity in use cases or 220 | requirements, then Editors should exit the current phase and 221 | enter a UCR phase. 222 | * Ultimately, some issues will need to be decided in face-to-face 223 | meetings, as only that format can provide sufficient emotional and 224 | conversational bandwidth. 225 | 226 | ## Within monthly cycles 227 | 228 | Solid Editors will maintain a monthly cycle. 229 | 230 | ### Nomination 231 | 232 | The cycle begins with Editors nominating issues from those registered 233 | on Github for consideration for the different phases of the following 234 | cycle. The community will have a comment period during which they may 235 | support or refute whether entrance criteria has been met by each issue 236 | for the relevant phase. During this period, the community is also 237 | expected to commit resources to help progress the issues through the 238 | phases. As the community commits resources, they may also timebox their 239 | efforts and thereby set effective due dates for the resolution or 240 | phase-advance of issues. 241 | 242 | A summary of the selected issues will be written, targeting a 243 | technical audience that does not follow the work closely. 244 | 245 | ### Weekly Assessment 246 | 247 | Solid Editors will convene weekly to assess issue progress, and may in 248 | those meetings re-phase issues depending on their progress, as well as 249 | discuss using the measures detailed in the above process. 250 | 251 | ### End of Month 252 | 253 | Solid Editors will convene monthly to review the achievements of the 254 | preceding month. The Editors will also attempt to reach conclusion on 255 | any issues that have not yet been resolved in the consensus phase. 256 | Editors will review any open Pull Requests. If they find that a 257 | Pull Request cannot be merged in near future, they will close it and 258 | open issues to resolve outstanding problems. 259 | 260 | A summary of the latest month’s achievements will be written, 261 | targeting a non-technical audience, explaining the anticipated 262 | benefits for users, organizations, and developers. 263 | -------------------------------------------------------------------------------- /stakeholders.md: -------------------------------------------------------------------------------- 1 | # Solid Stakeholders 2 | 3 | Below is a listing of [Solid Stakeholders](README.md#stakeholders). Stakeholders are those affected by normative changes to the Solid Specification, Solid Roadmap, or Supporting Documentation. 4 | 5 | Stakeholders who have opted to identify themselves publicly are listed below. 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. 6 | 7 | Dishonest submissions, or submissions which violate the [Code of Conduct](code-of-conduct.md) are subject to removal. 8 | 9 | ## Stakeholders 10 | 11 | ### Identity Providers 12 | 13 | | Name | Identity Provider URL | 14 | | --------- | ---------- | 15 | | [Inrupt](https://inrupt.com) | https://inrupt.net/ | 16 | | [OpenLink Software](http://www.openlinksw.com) |
  • https://solid.openlinksw.com:8444
  • https://solid.openlinksw.com:8445
    • | 17 | 18 | ### Pod Providers 19 | 20 | | Name | Pod Provider URL | 21 | | --------- | ---------- | 22 | | [Authing](https://authing.cn/) | https://solid.authing.cn | 23 | | [Inrupt](https://inrupt.com) | https://inrupt.net/ | 24 | | [OpenLink Software](http://www.openlinksw.com) |
  • https://solid.openlinksw.com:8444
  • https://solid.openlinksw.com:8445
    • | 25 | 26 | 27 | ### Application Providers 28 | 29 | | Name | Application URL | 30 | | --------- | ---------- | 31 | | --------- | [Dechat_es5b](https://arquisoft.github.io/dechat_es5b/) | 32 | | --------- | [Dechat_es6b](https://arquisoft.github.io/DeChat_es6b/) | 33 | | 5 Apps | [Solid Notify](https://solid-notify.5apps.com/) | 34 | | [Alain Bourgeois](https://github.com/bourgeoa) |
  • [Tiddlywiki](https://bourgeoa.solid.community/public/tiddlywiki)
  • [Solid File Widget](https://bourgeoa.solid.community/public/solid-file-widget/)
  • [Solid authorization Widget](https://bourgeoa.solid.community/public/solid-file-widget/)
    • | 35 | | [Allmende Lab](https://lab.allmende.io) | [Solidbase](https://app.solidbase.info) | 36 | | [Andrei Sambra](https://github.com/deiu) |
  • [Plume](https://thewebalyst.solid.community/plume/)
  • [Contacts](https://github.com/linkeddata/contacts)
  • [Inbox](https://solid.github.io/solid-inbox/)
  • [Warp](https://linkeddata.github.io/warp/)
  • [Solid Signup app](https://github.com/solid/solid-signup)
  • [WebID Profile editor](https://linkeddata.github.io/profile-editor/)
    • | 37 | | [Angelo Veltens](https://gitlab.com/angelo-v) | [Solid Profile Viewer](https://profiles.veltens.org) | 38 | | [Contributors](https://github.com/Arquisoft/dechat_es3b/graphs/contributors) | [Dechat_es3b](https://arquisoft.github.io/dechat_es3b/) | 39 | | [Contributors](https://github.com/Arquisoft/dechat_es5a/graphs/contributors) | [Dechat_es5a](https://dechat5a.ddns.net/) | 40 | | [David Conorozzo](https://github.com/dconorozzo) | [File Extractor](https://formrouter.solid.community/public/FileExtraction/) | 41 | | Dylan Martin | [Solid Calendar](https://bitbucket.org/dylanmartin/solidcalendar/src/master/) | 42 | | [FactsMission](https://factsmission.com) | [Twee-Fi](https://factsmission.github.io/twee-fi/) | 43 | | [FormRouter Inc](https://www.formrouter.com) |
  • [Form Integration](https://www.formrouter.com/solid-project-pod-pdf-form-integration/online_forms_solid_pod.htm)
  • [File Extractor for Pods](https://github.com/dconorozzo/Solid-RDF-HexBin-File-Extraction)
    • | 44 | | [graphMetrix](https://graphmetrix.com/#/solid) | [graphMetrix](https://graphmetrix.net/#/) | 45 | | [Inrupt](https://inrupt.com) | [Solid React SDK by inrupt](https://github.com/inrupt/solid-react-sdk) | 46 | | [Jakub Klimek](https://github.com/jakubklimek) | [LinkedPipes Applications](https://applications.linkedpipes.com) | 47 | | [James Cole](https://github.com/JC5) |
  • [Firefly-iii](https://github.com/firefly-iii/firefly-iii)
  • [Find Solid Pods](https://findsolidpods.com)
    • | 48 | | [Jeff Zucker](https://github.com/jeff-zucker) | [Solid Shell](https://github.com/jeff-zucker/solid-shell) | 49 | | [Jeff Zucker](https://github.com/jeff-zucker) |
  • [Solid IDE](https://jeff-zucker.github.io/solid-ide/)
  • [SPARQL Fiddle](https://jeff-zucker.github.io/sparql-fiddle/)
    • | 50 | | [Karel Dvořák](https://github.com/carloss8) | [Pixolid](https://pixolid.netlify.com/) | 51 | | [Licensors](https://github.com/Arquisoft/dechat_en1b/graphs/contributors) | [Dechat_en1b](https://arquisoft.github.io/dechat_en1b/) | 52 | | [Licensors](https://github.com/Arquisoft/dechat_en2a/graphs/contributors) | [Dechat_en2a](https://arquisoft.github.io/dechat_en2a/) | 53 | | [Licensors](https://github.com/Arquisoft/dechat_en3a/graphs/contributors) | [Dechat_en3a](https://arquisoft.github.io/dechat_en3a/) | 54 | | [Licensors](https://github.com/Arquisoft/dechat_es1a/graphs/contributors) | [Dechat_es1a](https://arquisoft.github.io/dechat_es1a/) | 55 | | [Licensors](https://github.com/Arquisoft/dechat_es1b/graphs/contributors) | [Dechat_es1b](https://arquisoft.github.io/dechat_es1b/) | 56 | | [Licensors](https://github.com/Arquisoft/dechat_es2b/graphs/contributors) | [Dechat_es2b](https://arquisoft.github.io/dechat_es2b/) | 57 | | [Licensors](https://github.com/Arquisoft/dechat_es4a/graphs/contributors) | [Dechat_es4a](https://arquisoft.github.io/dechat_es4a/) | 58 | | [Licensors](https://github.com/Arquisoft/dechat_es4b/graphs/contributors) | [Dehat_es4b](https://arquisoft.github.io/dechat_es4b/app/) | 59 | | [Licensors](https://github.com/Arquisoft/dechat_es6a2/graphs/contributors) | [Dechat_es6a2](https://arquisoft.github.io/dechat_es6a2/) | 60 | | [Licensors](https://github.com/Arquisoft/sole_chat/graphs/contributors) | [Dechat_en2b/sole_chat](https://arquisoft.github.io/sole_chat/) | 61 | | [Melvin Carvalho](https://github.com/melvincarvalho) |
  • [Hello World](https://melvincarvalho.github.io/helloworld/)
  • [Mark Book](https://markbook.org)
    • | 62 | | [Noel de Martin](https://github.com/NoelDeMartin) | [Solid Focus](https://noeldemartin.github.io/solid-focus/) | 63 | | [OpenLink Software](http://www.openlinksw.com) |
  • [OpenLink Structured Data Editor (OSDE)](http://osde.openlinksw.com)
  • [OpenLink Structured Data Sniffer (OSDS)](http://osds.openlinksw.com)
  • [URIBurner](http://linkeddata.uriburner.com/sparql)
  • [OpenLink Smart Data Bot (OSDB)](http://osdb.openlinksw.com)
  • [ODS-Briefcase](http://ods.openlinksw.com/wiki/ODS/OdsBriefcase)
  • [OpenLink YouID](http://youid.openlinksw.com)
    • | 64 | | [Otto AA](https://github.com/Otto-AA) | [Solid File Manager](https://otto-aa.github.io/solid-filemanager/) | 65 | | [Pieter Heyvaert](https://github.com/pheyvaer) |
  • [Solid Chess](https://pheyvaer.github.io/solid-chess/)
  • [Tadanime](https://pheyvaer.github.io/tadanime/index.html)
    • | 66 | | [Sarven Capadisli](https://github.com/csarven) | [Dokieli](https://dokie.li) | 67 | | Startin Blox | [Referendum Signons](https://referendum.signons.fr)| 68 | | [Taisuke Fukuno](https://github.com/taisukef) | [Taisukef](https://taisukef.github.io/solid-addfriend/) | 69 | | Vincent Tunru | [Poddit](https://vincenttunru.gitlab.io/poddit/) | 70 | | [WEBIND](https://www.webind.de/) | [A-PHEVOS](https://phevos.tk) | 71 | | [Webize](https://github.com/webize) | [2048](http://webize.github.io/2048/) | 72 | 73 | ### Users 74 | 75 | | Name | WebID | 76 | | --------- | ---------- | 77 | | [Kingsley Idehen](https://github.com/kidehen) |
  • [WebID 1](https://kidehen.solid.openlinksw.com:8444/card#me)
  • [WebID 2](https://kidehen.solid.openlinksw.com:8445/card#me)
    • 78 | | [Tim Berners-Lee](https://github.com/timbl) | [WebID](https://www.w3.org/People/Berners-Lee/card#i) | 79 | -------------------------------------------------------------------------------- /system-operators.md: -------------------------------------------------------------------------------- 1 | # solidcommunity.net maintainers 2 | 3 | Below is a listing of maintainers, who provide administrative support 4 | and operational management of [solidcommunity.net](https://solidcommunity.net). 5 | 6 | ## Maintainers 7 | 8 | | Name | WebID | 9 | | --------- | ---------- | 10 | | [Alain Bourgeois](https://github.com/bourgeoa) | [WebID](https://bourgeoa.solid.community/profile/card#me) | 11 | | [Eric Prud'hommeaux](https://github.com/ericp) | [WebID](https://ericp.solidcommunity.net) | 12 | | [Michiel de Jong](https://github.com/michielbdejong) | [WebID](https://michielbdejong.solidcommunity.net/profile/card#me) | 13 | | [Justin Bingham](https://github.com/justinwb) | [WebID](https://justin.inrupt.net/profile/card#me) | 14 | | [Jackson Morgan](https://github.com/jaxoncreed) | [WebId](https://jackson.solidcommunity.net/profile/card#me) | 15 | | [Mahdi Baghbani](https://github.com/MahdiBaghbani) | [WebId](https://mahdi-baghbani.solidcommunity.net/profile/card#me) | 16 | -------------------------------------------------------------------------------- /test-suite-panel-charter.md: -------------------------------------------------------------------------------- 1 |
    2 | Document Status 3 |
    4 |
    Modified
    5 |
    2023-11-14
    6 |
    Reason
    7 |
    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.
    8 |
    9 |
    10 | 11 | --- 12 | 13 | # Test Suite Panel Charter 14 | 15 | The mission of the Test Suite Panel as part of the W3C Solid Community Group (CG) is 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. 16 | 17 | * Start date: 2022-07-01 18 | * End date: 2025-06-30 19 | * Charter extension: The charter extension history is documented in "About this charter". 20 | * Confidentiality: Proceedings are public 21 | * Chair: [Sarven Capadisli](https://csarven.ca/#i) 22 | * Team Contact: Solid Editors 23 | * Usual Meeting Schedule: Teleconferences: Occur on a need to basis. The chair may call for topic-specific calls when needed and may change working mode as work progresses. 24 | 25 | ## Goals 26 | 27 | The Test Suite Panel 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. 28 | 29 | Writing tests in a way that allows implementations to conform to the requirements of a technical report gives Solid projects confidence that their software is compatible with other implementations. This in turn gives 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. Implementation and interoperability experience can be verified by reporting on implementations passing open test suites. 30 | 31 | The panel will develop open source conformance testing software, author and review tests, release implementation reports, and provide feedback to technical report development. 32 | 33 | The work will be driven and refined by: representative tests for technical reports; quality control and assessment of test suite software; tests; and reporting. 34 | 35 | The panel will collaborate with other Solid panels and may take on or pass on challenges. 36 | 37 | The panel will contribute to the development of technical reports and releasing implementation reports as necessary, which may require re-chartering, e.g., to provide tests for new technical reports in the future. 38 | 39 | ## Scope 40 | 41 | The panel within the framework of the W3C Solid CG and the Solid Project will complement the development of technical reports and support the communication of implementation reports. Features that are not implemented due to time constraints can be put into a non-normative "roadmap" document for future work. The scope will include: 42 | 43 | * Human- and machine-readable units of information at any level of granularity are available from technical reports, test reviews and reports, test suite design, test environment and setup, individual tests, and software implementations. 44 | * Evaluation tools (software programs or online services) that help determine implementation conformance. 45 | * Vocabularies for technical reports, test suite design, tests, and test reports. 46 | * Documentation detailing setting up a test environment, authoring and running tests, reviewing tests, and publishing reports. 47 | * Guidelines for improving conformance and variations among conforming implementations. 48 | * Communicating the level of adoption of technical reports. 49 | 50 | Other components necessary for building conformance test software, authoring and reviewing of tests, and communicating implementation reports are in scope but will not lead to a deliverable without re-chartering, and should be discussed in the Test Suite Panel. 51 | 52 | ### Success Criteria 53 | 54 | Test reports and summaries including required human- and machine-readable information (regardless of the mechanisms used to produce the documents). 55 | 56 | Publication of approved test reports. 57 | 58 | All deliverables should detail all known security and privacy implications for testers and implementers where applicable. 59 | 60 | There should be testing plans for each technical report, starting from the earliest drafts. 61 | 62 | To promote interoperability, new tests or modifications to existing tests should be available when there are changes to technical reports, or must include the rationale for why test updates are not required for the proposed update. 63 | 64 | ## Deliverables 65 | 66 | ### Normative Deliverables 67 | 68 | The panel will deliver the following to fulfill its goals, subject to discussion in the Solid CG: 69 | 70 | * Test conformance software. 71 | * Tests, test reviews, test reports. 72 | * Processes to author, review, and publish tests and reports. 73 | 74 | The Test Suite Panel will share its findings towards improving technical reports and implementations. 75 | 76 | ### Other Deliverables 77 | 78 | The panel may deliver the following: 79 | 80 | * Best Practices and Guidelines to support test authors when designing tests. 81 | * Guidance for implementation conformance. 82 | * Document and inform about the level of adoption of technical reports. 83 | 84 | ### Milestones 85 | 86 | The production of the deliverables depends upon the resources available, and will change as new technical reports are published and implementation experience is reported to the group. The most up-to-date timeline is available from the panel repository. 87 | 88 | Note: The Test Suite Panel as part of the W3C Solid CG does not publish technical reports under the W3C Recommendation track. Thus, any classification pertaining maturity level of potential technical reports are intended to be roughly equivalent to section 6.2.1 of the W3C Process. 89 | 90 | ## Coordination 91 | 92 | Technical coordination with the following Groups may be required: 93 | 94 | ### W3C Groups 95 | 96 | * [Evaluation and Repair Tools Working Group](https://www.w3.org/WAI/ER/) 97 | * [Accessibility Guidelines Working Group](https://www.w3.org/WAI/GL/) 98 | * [Spec Editors Community Group](https://www.w3.org/community/speced-cg/) 99 | 100 | Furthermore, the panel expects to follow the following W3C Recommendations, Guidelines, and Notes, and, if necessary, to liaise with the communities behind them: 101 | 102 | * [Internationalization Technical Reports and Notes](http://www.w3.org/International/publications) 103 | * [QA Framework: Specification Guidelines](http://www.w3.org/TR/qaframe-spec/) 104 | 105 | ### External Groups 106 | 107 | The panel may correspond with the [web-platform-tests Project](https://github.com/web-platform-tests/wpt). 108 | 109 | ## Participation 110 | 111 | Membership in the W3C Solid CG is required to participate in the Test Suite Panel. All work and communication within the Solid CG is covered by the [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md) as well as the [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/). 112 | 113 | To be successful, the Test Suite Panel is expected to have 5 or more active participants for its duration and to have the participation of contributors to technical reports, test suite developers, software implementers, test authors, and reviewers. The Chair, test suite developers, and contributors to technical reports are expected to collectively contribute one day per week towards the Panel. The Chair may call occasional meetings consistent with the W3C Process requirements for meetings. There is no minimum requirement for other Participants. 114 | 115 | The Test Suite Panel will also allocate the necessary resources for building test suites for each technical report. 116 | 117 | The group encourages questions and comments on its project repository, as described in Communication. 118 | 119 | ## Communication 120 | 121 | Most Test Suite Panel Teleconferences will be conducted on an as-needed basis. 122 | 123 | Most of the technical work of the panel will be done through: 124 | 125 | * Repository: https://github.com/solid/test-suite-panel 126 | * Discussions: https://gitter.im/solid/test-suite 127 | 128 | Individual work items are expected to use other repositories. 129 | 130 | Information about the panel (for example, details about deliverables, issues, actions, status, and participants) will be available from the Test Suite Panel repository. 131 | 132 | ## Decision Policy 133 | 134 | As explained in the W3C Process Document (section 5), this group will seek to make decisions when there is consensus and with due process. The expectation is that 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, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation -- using, for example, chat channel or panel repository) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available. 135 | 136 | This charter is written in accordance with Section 5.2.3, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires. 137 | 138 | ## Licensing 139 | 140 | The panel will use the MIT license for all its deliverables. 141 | 142 | ## Patent Policy 143 | 144 | This W3C Solid Community Group operates under the W3C Community Contributor License Agreement (CLA). 145 | 146 | ## About this Charter 147 | 148 | This charter for the Test Suite Panel has been created according to section 5.2 of the W3C 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. 149 | 150 | ### Charter History 151 | 152 | The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3): 153 | 154 | | Charter Period | Start Date | End Date | Changes | 155 | |-----------------|------------|------------|------------| 156 | | Initial Charter | 2022-05-09 | 2022-06-14 | | 157 | --------------------------------------------------------------------------------