Solid Information Structure

[Mitzi-Laszlo]

How do we want people who are unfamiliar to Solid to absorb the information and orient themselves? I have described imperfect suggestions designed to open up conversation to come to a conclusion together. It's particularly important to me that those who have already worked on key elements are involved in what they already had in mind. There is no need to reinvent the wheel, rather just to explain where the wheel is.

I have been working on the Community Repo as a starting point to give oversight https://github.com/solid/community. Do we want to continue with this as a starting point? Are there any improvements we could make to the introduction, for example, key items to include?

The Goals are described in the spec and architecture in the community readme. solid-architecture, solid-spec, and web-access-control-spec are three repos that could be included in the community repo or kept separate. Preferences? Perhaps the architecture could give a map of all non governance repos to give a visual of each of the functions and their interplay.

Some information is doubled up in the community repo and other repositories. From a macro perspective, what would be the most logical distribution of this information?

A few suggestions...

We need a place for solid resources, including talks on Solid, articles of Solid, as well as general resources online that are useful for understanding Solid. https://github.com/solid/community/blob/master/solid-resources.md was designed with this aim in mind. However, the following items cover similar material and could be coordinated: solid-tutorial-intro, solid-tutorial-angular, solid-tutorial-rdflib.js, profile-viewer-tutorial, understanding-linked-data, solid-tutorial-pastebin, web-summit-2018, intro-to-solid-slides. We could create links to the repos or merge the information into the solid-resources.md. Preferences?

https://github.com/solid/vocab and https://github.com/solid/community/blob/master/solid-dictionary.md are covering similar material - how could we intertwine these?

https://github.com/solid/solid-apps and https://github.com/solid/community/blob/master/solid-apps.md are covering similar material - how could we intertwine these?

https://github.com/solid/userguide has some great introductory material, when should a newbie be introduced to this?

https://github.com/solid/releases where should this live and how should it link to the community repo?

Any thoughts on how and when newbies should run into:
https://github.com/solid/solid-namespace
https://github.com/solid/solid-platform
https://github.com/solid/solid.mit.edu

[csarven]

IMO, if there is a repo with a specific purpose, migrate relevant information that's elsewhere to that repo. Treat the dedicated repo as canonical. Refer to that from elsewhere.

I don't understand why https://github.com/solid/community/blob/master/solid-apps.md exists when https://github.com/solid/solid-apps predates it and used. There is also no provenance (like "derived from" or "copied from").

As vocab and solid-dictionary, they have different purpose and material.

[csarven]

I was thinking that perhaps some information can be self-managed by the community. I'm not sure if repos like solid-apps need to be processed through PRs. A (GitHub's) wiki may serve just fine as long as there is a change history and a way for managers/admins or whatever to roll back.

[justinwb]

@csarven One argument for having solid-app additions go through pull requests is to have some measure of checking that an app is well-intentioned and not malicious. Still not a perfect system by any means, and there's no guarantee that PR approval would catch everything, but there's at least some measure of quality checking before something gets listed.

[csarven]

@justinwb Sure, PR works too. Created https://github.com/solid/solid-apps/issues/18 in any case.