[New Work Item]: Solid26 Implementors Guide

[jeswr]

This is a new work item proposal to create an implementors guide, similar to the verifiable credentials implementors guide.

A publicly accessible draft can be found on the primer tab of a google doc. I will shortly be porting this to html and creating a draft PR to this repository with these contents.

Explain what you are trying to do, using no jargon or acronyms.

Solid26 is a planned collection of Solid specification versions (written as a new implementors guide), best practices, and documentation intended to give developers, organisations, and communities a stable target to build against. This does not change or remove existing parts of the Solid Specification in any way. Solid26 adds to the existing set of resources in the Solid Community, and is aims to make Solid more accessible.

We also provide a longer write-up of Solid26

How is it done today, and what are the limits of the current practice?

Server implementors pick the set of documents versions they wish to build against - and is one of the reasons there are inconsistencies across server implementations in the ecosystem.

What is new in your approach, and why do you think it will be successful?

The new approach creates an implementation guide recommending versions for server and application implementors alike to build against for the next 6-12 months. This has the following benefits:

• If feedback is collected on Solid26, it is clear which versions of specifications feedback is being provided on
• It unblocks some organisations (which need stability guarantees before working with new technologies) from implementing Solid

How are you involving participants from multiple skill sets and global locations in this work item? (Skill sets: technical, design, product, marketing, anthropological, and UX. Global locations: Africa, the Americas, APAC, Europe, Middle East, Antarctica.)

This is designed to be a lightweight document referencing other specifications which are developed by multidisciplinary participants. Hence this is largely non-applicable for this work item.

What actions are you taking to make this work item accessible to a non-technical audience?

The goal is to improve accessibility (to implementors) of the existing TR specifications. Surrounding this work item within the CG, the proposers of this work item are also developing:

• best practices and documentation for technical audiences,
• UX demos, briefing materials and publicity for non-technical audiences.

[elf-pavlik]

I think this is a good idea and this issue can serve as a place to collect early feedback. Once you have the PR ready we should probably focus on discussing details there.

EDIT: It may be better to have a separate repo for it, so we don't ignore open issues. Once there are 190 existing ones then 200 or 210 don't seem any different and we will less likely try to resolve them.

As for conclusion to https://lists.w3.org/Archives/Public/public-solid/2026Mar/0019.html If the initial PR includes the outcomes it could simply be shared as the outcome. Otherwise a followup PR could serve this purpose. Either way we should close that thread with a clear outcome whenever it is available.