Should client-to-client specs all be under ONE centralized repository?

[VirginiaBalseiro]

This is a topic that was proposed by @timbl, so I decided to give the Discussions feature a go before we go and create issues if needed.

During the 2023-03-01 Community Group meeting, we had a discussion about shapes reuse, and whether we should have a dedicated repository to gather shapes and collaborate on them. During this discussion, @timbl proposed having a single repository for all client-to-client specifications, including WebID Profile, Type Index, and potentially future work on Contacts or Chat, since it'd be optimal if shapes live alongside the corresponding specification to make them more useful, while at the same time having all these specs in a place where they are easy to find and easier to review.

I am opening this discussion space so that we can evaluate this proposal and decide what are the next steps, if any.

I am hereby also inviting @timbl to elaborate on his proposal, reasoning, benefits, and so on, and also anyone to voice your opinions on this thread.

[timbl]

(Interesting you can make a new issue from a discussion like we want in SolidOS) ..

I wasn't suggesting ALL client - client specs go in one repo, just core ones, like profile and contacts and maybe chat. Not financial, fitness, health, recipes, and so on. I passionately don't care about the details of exactly which repos we use, so long as we have somewhere to work together. I'll go with the flow whatever others want to do.

[TallTed]

Note that GitHub has implemented "discussions" as semi-threaded Q&A conversations. The initial post is the Q, and all replies to that initial post are the As. All replies to those replies are treated as comments thereon (that is, there is no further, deeper threading). I have found these "discussions" to be one of the least useful attempts at reinventing NNTP (still the best implementation of threaded discussions on the Internet, even if NNTP never quite made it into proper multi-media messaging)... But your mileage may vary. If you find them useful, enjoy!

[csarven]

I do not quite see the benefit of using a single repository for specifications (or work items). This is based on the observation in the CG that the contributors and contributions appeared to work "better" when there are dedicated repositories to manage issues, processes, access controls, and so forth. In fact, when some of the panels originally worked on multiple specifications in their single repository, we found the need to split out the specification into their own repositories.

[timbl]

ok, I bow to experience

[csarven]

Feel free to move (copy/paste) this to a separate issue or discussion, but since the original discussion started off shape reuse, I'd like to suggest the following:

• A single GitHub repository for shapes under the Solid org.
• Shapes in the repository must be referred by Solid specifications.
• Set workflow to have each shape available from a URL, e.g., http(s)://www.w3.org/ns/solid/shapes/{shortname}.

---

Background/Justification for the curious:

The management of the shape repository and publication can be same as https://github.com/solid/vocab . None of works there belong to a particular group but there is a process on accepting changes across groups and time. I created that repo because we needed to coordinate in an open and transparent fashion.

I'll refer to a couple of examples from the W3C to point out how ns/solid/* does not belong to the Solid CG (or any other group), because the same will ultimately apply to the publication of Solid shapes:

• The ns/ldp didn't belong to the LDP WG (or the LDP-Next CG). When the Social Web WG requested to add ldp:inbox to the LDP vocabulary, the fundamental requirement was to show that a specification, i.e., LDN, needed it.
• In the same way, ns/activitystreams didn't belong to the Social Web WG (or the Social Web Incubator CG) given that years later the DID WG requested the addition of as:alsoKnownAs, which was granted by showing that the DID specification needed it and used it.

There is no need to constrain the shape repository to specific interoperability between classes of products, e.g., for particular (not all) "client to client" shapes. Again, the shapes can ultimately it'd be backed by or can work with one or more specifications. So, a single shapes repository would serve as a place to eventually publish them somewhere (just like solid/vocab) but is not intended to hold any random shape.

[VirginiaBalseiro]

I personally agree with @csarven's comments.

[VirginiaBalseiro]

Feel free to move (copy/paste) this to a separate issue or discussion, but since the original discussion started off shape reuse, I'd like to suggest the following:
A single GitHub repository for shapes under the Solid org.
Shapes in the repository must be referred by Solid specifications.
Set workflow to have each shape available from a URL, e.g., http(s)://www.w3.org/ns/solid/shapes/{shortname}.

@csarven What would be the proper place to open an issue with these points and discuss during CG meeting(s)?

I have created an issue to follow up on the shapes reuse discussion here: solid/specification#506