Applying the proposed guidelines to repositories under github.com/solid

[justinwb]

Checklist: 👍 Proposed issue text: 👍 Explicit date (April 15th): 👍 (assuming this is approved in time that people have at least two weeks to respond)

[timea-solid]

I cannot overlook this question: how will a new person to Solid understand all spaces? If we make this move, this will mean: a new person might find current solid space and hopefully they will understand it is all specifications and processes. If I am a developer and want to get started and see example apps I would have these questions: 1) Where do I find examples easier 2) What is the difference between official contrib codes and code that is not on contrib space? 3) How can I get my code on the contrib space?

Also, if every project moves to its own space, how can a newcomer have an overview of Solid with specs and examples? This is already difficult as is: servers, apps, frontend ... example community apps... but at least we had one common space for some of it, at least for code developed by Solid contributors (admins, creators, editors). Counter proposal: leave the projects developed by admins, creators, editors on the space too. (Projects means also solid code examples and apps and libs). Any thought on this side-effect of the move?

[justinwb]

Also, if every project moves to its own space, how can a newcomer have an overview of Solid with specs and examples?

This is an important point. IMO it should be addressed by a more user-friendly avenue (e.g. solidproject.org). I don't think having 100+ repos in the same github organization is helping anyone. To @theRealImy's point then - I think consider what resources we can put in place (and where to put them) to point people in the right directions.

[kjetilk]

I think it is very worthwhile to clean up the repository, as it is very confusing. I think solid-contrib is a good idea, but I don't understand what makes solid-archive valuable, as archived repositories are clearly marked as such in the list of repositories and will not get the same prominence. When archived, they already have the metadata required that was asked for by @timbl in the original issue, and the UI is there to support it.

[kjetilk]

My thinking is that if we move stuff, there should be some clear value to do doing that. I don't see any value of moving stuff that should simply be archived, then just archive it in place.

I see benefit in cleaning up stuff that doesn't have any particular standing in the community, but it has to be balanced with the cost of possibly fragmenting the ecosystem, having to set up teams, adding cost to review stuff, and so on. To move stuff, this balance should clearly be in the positive.

[bourgeoa]

Implementations are not neutral; they make certain decisions regarding implementations.

This imply removing all solid history and relation between implementation and specification. This is quite a harsh step. Clarification is good, but making it a white page has some signification.

This remove auth, namespace, nss, mashlib, solidcommunity.net, tests ...

In a way this disregard the effort made by community contributors to solid by way of implementations and not only to specification.

Does solid/team do not cover some form of community management ? Does solid-contrib reflects the community involvement ? Be it university contributions or individuals ... ?

[kjetilk]

I agree that we shouldn't be picking favorites, but I also think that it is over the top to remove all that, this is a community after all.

I think we shouldn't say that a place in the Solid org implies endorsement, only that it is a valid contribution, and so the Team would then need to define what a valid contributions is.

[kay-kim]

One minor thing (and it may be nothing, so feel free to disregard), but I wonder if we could be a smidge clearer about the site reorg since we state that we want the site to host authoritative documents and we link to a process where the various Solid teams (editors, creators, administrators) are a bit heavy with Inrupt people. I feel like this could lead people to assume the content will lean towards Inrupt when that is not what we're trying to do.

Although, your suggestion to put everything into solid-contrib might actually resolve that. But, it might not hurt to explicitly state (as you did in your reply above) that even project/code/examples from editors, creators, administrators would also go under solid-contrib.

[csarven]

I think we should keep some of the spec tests repos remain under solid org. We need the tests to be authoritative and neutral from the CG's perspective. If we move them out of solid/ we lose a bit of that credibility long term. solid-contrib is a reasonable but temporary solution. However, that still feels a bit strange org where the tests can live on.

We need the specs to link to the tests and implementation reports that's in neutral space - preferably managed by a group.

I say as someone that took on the hosting and management of the LDN tests (under linkedresearch.org ) and at the time the WG was okay with that. I don't think the Chairs should've allowed that to happen. Because right now the spec links to it, I control the domain, hosting, tool etc.. including the reports. In a long enough timeline, I will get hit by a bus.

Just as the spec repos are under the solid org, so should their tests/reports that are acknowledged by the CG. If we just need to call out what's approved/authoritative from the CG's perspective, we can do that - that's where we need to be in any case. Then the key tests can remain under solid org and the rest - if not associated with a spec that's listed as a Work Item under https://solidproject.org/TR/ , then they can move out. We can in fact do that today.

[kjetilk]

If we just need to call out what's approved/authoritative from the CG's perspective, we can do that - that's where we need to be in any case.

My proposal is the other way round: let's move tests into /solid when they are approved. So this move is temporary.

I think moving back and forth will be confusing, I would not think that would be a great service to the community.

Moreover, the conformance test suite does this the right way already, it indicates in the test description what the status of a test is. Whether a test has been approved is noted on a very detailed level and can be used by the toolchain (and is already being used). This is a much better way of doing it than relying on moving it around temporarily.

Other than that, I can live with solid-contrib if we can ensure that it does not incur too much cost in administration of accesses.

[jaxoncreed]

I believe the only thing left to do on this task is update the Solid Website. @jeff-zucker is that something you can do?

[timea-solid]

I believe the only thing left to do on this task is update the Solid Website. @jeff-zucker is that something you can do?

This task is done. The remaining task has its own ticket now: https://github.com/solid/team/issues/23#issuecomment-1379426860 Last year we said we are going to mention that on the website with pointers to repos. @jeff-zucker too the action last year. So this ticket can be closed form my point of view.