Created: 2025-04-01
Modified: 2025-04-07
Effective: 2025-05-01
The aims of the Solid Project are in line with those of the Web itself: empowerment towards "an equitable, informed and interconnected society" [ethical-web-principles]. Solid adds to existing Web standards to realise a space where individuals and communities can maintain their autonomy, control their data and privacy, and choose applications and services to fulfill their needs.
The mission of the Solid Practitioners is to support those involved in putting the Solid vision into practice in the real world, to publicize their efforts, to find opportunities for networking and collaboration, to foster a sense of an inclusive and welcoming global community.
The target audience of this group is people actively working on projects aimed at specific real-world products using Solid, especially open source products, and products which promote social benefit. Everyone interested in Solid, regardless of involvement in a project or technical skill level, is encouraged to participate while recognizing that the discussions will be focused on challenges of member projects, not generalized developer support, although the two will certainly overlap in many cases.
In addition to Solid developers and would-be developers, the group will seek to include domain experts in fields relevant to member projects (healthcare, transportation, housing, etc.) and technical experts from outside of Solid where their expertise is relevant to member projects. Community members expressing needs that Solid may address are also encouraged to attend regardless of their knowledge of Solid or technology.
Projects in the global south as well as those serving marginalized communities are strongly encouraged to attend.
The focus of the Solid Practitioners Group will be on supporting active projects working on specific products and on "getting things done with what exists" rather than on theoretical issues or general developer support. Special attention will be paid to open source projects and to projects providing social benefit. Our approach will be from the bottom up — a community or group of users has a need; an individual or team of developers works in conjunction with that community to produce a product that addresses the need; the individual or team participates in Solid Practitioners and can then network and discuss with similar projects the technical and social barriers they face.
In addition to our main focus — providing working sessions on challenges faced by member projects — we will focus on networking between member projects; for example, exploring code reuse and commonalities in assessing the social impact of the projects and measures for adoption of Solid in local communities.
In addition to technical issues, the group's discussion will include the social impact of member projects, issues related to publicizing those projects, and the adoption of those projects by public agencies and other organizations. We anticipate an effort to help highlight and publicize our member projects and success stories and to document best practices discovered by the group or individual projects. This publicizing will include development of a Solid Resources Catalog, participation in public events such as Solid World and the Solid Symposium, and coordination with the solidproject.org website to highlight our member successes.
- 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 and social advantages/disadvantages and applicability to member projects.
The Solid community with various stakeholders comes together under the umbrella of the Solid Project, stewarded by the Open Data Institute (ODI). Thus the Solid Practitioners Group interacts and coordinates with the Project's organisation as a whole and will elect a representative to serve on the ODI Solid Advisory Committee.
An important ongoing goal will be to provide feedback to
- the W3C Solid Community Group, especially on implementer experience and needs related to specifications, ontologies, shapes, and other technical infrastructure
- the W3C Linked Web Storage Working Group, especially on use cases.
- the ODI Solid Advisory Committee especially on developer and community feedback on the goals and roadmap for the Solid Project.
As part of the group's goal of publicizing and helping network member projects and to integrate member use cases in the work of the Solid Community Group, Linked Web Storage Group, and ODI, we will be developing a form to gather data on our member projects. Members are strongly encouraged to update the form so that the broader community can follow and support their efforts and to ensure that their work contributes to the goals of Solid itself.
All discussions for the Practitioners Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and 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.
- Meeting notices and minutes as well as issue discussions are available at https://github.com/solid-contrib/practitioners/
- Online meetings are held at https://meet.jit.si/solid-practitioners
- More informal discussion is encouraged in the https://matrix.to/#/#solid-practitioners:matrix.org
- Video recordings of some meetings are available at https://spectra.video/c/solid_practitioners
A public mailing list for general discussions and announcements is under development.
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 Practitioners Group.
All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs.
The Practitioners Group will use the following licenses for its artefacts:
- Status reports and minutes from meetings will be released under CC BY-ND 4.0.
- Other reports will be released under CC BY-SA 4.0.
- Software artefacts developed by the Practitioners Group as a whole may be released either under the MIT License, the Apache License 2.0 or Mozilla Public License 2.0.
The Practitioners Group strongly encourages its participants, as well as other stakeholders in the Solid ecosystem, to use an OSI approved license for any open source software conforming to Solid specifications.
A general participant of the Practitioners Group can be an individual representing themself or an organization.
Any participant of the Practitioners Group is eligible to vote on elections, charter amendments, and other community matters so long as they have met the criterion laid out below.
A participant may vote in the election, if they have:
- attended 3 meeting in the previous two years cycle or since the inception of Solid Practitioners, or
- have contributed to a project that uses Solid and has attended 1 meeting in the previous two years cycle or since the inception of Solid Practitioners.
An affiliation MAY submit at most one ballot, that is, participants from the same affiliation other than the affiliation nominee shall be excluded from voting. An affiliation is defined here as being an employee of an institution such as an enterprise, university, or NGO. For these purposes students and independent members of open source projects will not be considered as affiliated with an institution. For voting and Chair nominees, the primary affiliation is their employer and will match their affiliation in the W3C and ODI databases. 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.
The Chairs will determine the list of eligible voting participants as of the record date. The Chairs will make the list available to the Practitioners 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 ODI Solid 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.
Any participant in violation of Solid Code of Conduct that leads to a sanction other than a warning will not be eligible to vote for the period of that sanction.
The Practitioners Group participants shall appoint Chairs for the group. The role of the Chair is described in the Art of Consensus.
The chair MUST NOT be a member of the ODI Board or ODI Solid Leadership Team.
Participation as Chair is afforded to the specific individuals elected or appointed to those positions, and a participant’s seat MUST NOT be delegated to any other person.
Chair nominees and elected chairs per term MUST have unique affiliations.
Any participant found in violation of Solid Code of Conduct that leads to a sanction other than a warning will not be eligible to be chair for the period of that sanction.
- At any given time there may be up to three co-chairs, each holding one seat for a two year term, measured from their election date, which may be shortened if they step down or are removed.
- In the first election after ratification of this charter, all seats will be up for election. Thereafter, elections will be held once a year if there is a vacant seat.
- In the case of interim vacancy, the remaining chairs may appoint a co-chair for each open seat, and postpone the election, at their discretion. If the chairs do not take any action, the seat will automatically be up for election. Any such interim appointments shall hold the seat until the next election.
- Reelection is restricted to three consecutive terms, with the possibility of being re-elected after sitting out one election cycle.
- Current chairs will select a date for elections, with a nomination period of one weeks starting two weeks prior to the election.
- For an individual to run for election, they must self-nominate and make a statement regarding their background and why they are running, and their organizational affiliation on the group mailing list or github repository.
- The current chairs shall be responsible for determining the eligibility of the nominee, provided they are not a candidate. In case, no chair is available to meet this criterion, a
- The current chairs will host a conference call during the nomination period, during which candidates may make a statement and answer questions from the community.
- If, at the end of nominations, any given seat only has a single candidate, that candidate immediately wins that seat. There will be an election for any seat(s) with multiple nominees.
- If, after nominations, any given seat has no candidates, the remaining chairs after any election (if necessary for other seats), will address the vacancy as an interim vacancy, described above.
- To elect one of multiple candidates, a vote will be held by the election mechanism of Broda Count (ranked voting). If the vote remains tied, the winner shall be the candidate whose nomination was first recorded publicly on the group email list or github repository. A candidate must receive a preference from 50% of the ballots cast.
- Chairs may be removed from their duties through a no-confidence vote.
- If a participant of the community group wishes to call for the recall of a chair–for any reason–that participant must first privately communicate with the other chairs their desire and reason for doing so. Those chairs must give the participant an opportunity to discuss their concerns with a goal of resolving them. If, after 15 days, the participant feels their issues are not addressed, they may then escalate to a public call for a no confidence vote. If after 15 days, the participant has not made that call for a no confidence vote, the matter is dropped; any further attempts to remove the chair in question must begin with a new round of private communication.
- A public call for no confidence must be announced to the group email list or github repository stating the name of the chair subject to the recall and the names and emails of at least 3 participants of the group who thereby call for a recall. This announcement must come from the participant who initiated the private communication with the chairs to discuss their concerns. The other two supporting participants MUST reply to that email on the public list within 48 hours to confirm their support for a no-confidence vote of the chair in question.
- The other chairs must acknowledge the call for no confidence within 7 days of all three participants declaring their support.
- Within 30 days of a call for no confidence, the other chairs must hold a conference call at which the parties seeking no confidence will have an opportunity to present their case and participants of the group will be able to ask clarifying questions. The chair in question shall not moderate this call. They will, however, have equal time to respond during that same call to the case made against them.
- During the week following this conference call, participants may cast votes in favor or against the recall by posting to the email list. If affirmative votes cast that week (in favor of recall) comprise greater than two-thirds of the total votes cast, then the chair in question is removed and the seat shall be treated as an interim vacancy.
- Participants are not required to vote. Abstentions may be recorded; such abstentions shall not count towards the total number of votes when calculating the two-thirds majority.
- A Chair who has been removed may stand for re-election.
- Only one call for no-confidence, for one chair, may be in process at any given time. Priority shall be given to the first such vote to be publicly called. Any subsequent public calls must wait until any previous recalls are resolved, then must start with private communication as described above.
- Participants may propose amendments to the charter by making a formal request to the Chairs. The chairs shall issue a call for principled objections to the amendment. If, after a period of two weeks, no principled objections have been presented by current participants of the group, the amendment is approved.
- If a principled objection is posted to the mailing list or expressed in a regular call, then the chairs may either drop the amendment or proceed with a public vote.
- A public vote for on the amendment must be called by the chairs within two weeks of the principled objection.
- Such a vote will be open for two weeks, with ballots cast via the group’s public mailing list. Each participant of the group eligible to vote may cast one ballot, “yea” or “nay”. An amendment must receive “yea” on two-thirds of the votes cast, and the total votes cast must represent 5% or greater of the group's participants eligible to vote, to pass.
- The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.
- Changes to the Coordination does not constitute an amendment to the charter that requires a rechartering vote.