Applying the proposed guidelines to repositories under github.com/solid about team HOT 12 CLOSED

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?

from team.

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

from team.

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.

from team.

Hi @theRealImy,

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.

Like @justinwb, I agree that this is important. However, note that we currently do not have an answer to this question either. Code is already spread across multiple repositories etc., as also indicated.

So we need to independently solve this problem in any case, regardless of the move. Let's create a new issue for that.

1. Where do I find examples easier

To be answered by a new issue. (I would hope the website can help with that.)

2. What is the difference between official contrib codes and code that is not on contrib space?

There is no official code; neither in contrib nor elsewhere. We don't have a way/process for approving code.

github.com/solid-contrib is a parking space for repositories from github.com/solid that have not found their space yet.

3. How can I get my code on the contrib space?

Not; they're only for legacy projects from github.com/solid that have not moved yet.

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

I don't think we really had though. It's a mess of working and broken code, approved and non-approved code, secure code and raw username/passwords of public services.

Counter proposal: leave the projects developed by admins, creators, editors on the space too. (Projects means also solid code examples and apps and libs).

I think that's unfair to other developers who are not.

For that very reason, just to give some examples, I have already moved things like https://github.com/solid/query-ldflex/, https://github.com/solid/mavo-solid, https://github.com/solid/community-server/. These are some of the many projects that I have started, but which I feel unfairly got the status of "Solid-approved" whereas they are not.

from team.

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.

from team.

I don't understand what makes solid-archive valuable

Actually, I can equally move those to solid-contrib. Or perhaps the other way round; solid-contrib can not be used and everything can be moved to solid-archive instead, and we still have the archived metadata bit to add.

when archived, they already have the metadata required that was asked for by timbl in the original issue

Yes; but the team discussion was slightly different than that issue.

from team.

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.

from team.

there should be some clear value

To me, the value proposition is a neutral and high-quality /solid, no exceptions.
Implementations are not neutral; they make certain decisions regarding implementations. And no projects should be favored over others; I don't want to play favorites.

(Archived in-place would mistakenly give the signal: the Solid team endorses this; these are just old. Whereas they have never been endorsed in the first place.)

Would that be an acceptable value proposition?
Concretely, I would move everything into solid-contrib and get rid of solid-archive then.

from team.

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 ... ?

from team.

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.

from team.

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

Not namespace or solidcommunity.net.

But yes auth, NSS, Mashlib, tests. They are all opinionated.

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

I don't see how. It's not a value judgment.
Just a recognition that it would be unfair to promote some implementations over others.

Now, we are selectively promoting some implementers but not others.

I think we shouldn't say that a place in the Solid org implies endorsement,

We do not decide that though. It's what people see.

@kjetilk @bourgeoa May I please ask to move this discussion to solid/process#276? The scope of this proposal is discussed there. Here is a discussion of the action plan once there is agreement on scope.

from team.

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.

from team.

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.

from team.

We need the tests to be authoritative and neutral from the CG's perspective.

100% agree.
But until that is the case, I would temporarily move them out of /solid, such that everything under here is authoritative.

solid-contrib is a reasonable but temporary solution.

Emphasis on temporary indeed. However, I sincerely hope that the tests do not end up there; that's only a last resort if test suite maintainers choose to not create separate organizations for their tests.

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.

from team.

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.

from team.

All moves have been performed.

from team.

Also updated https://github.com/orgs/solid/people to match the list of repositories. Administrators are duplicated at solid-contrib.

from team.

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

from team.

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: #23 (comment)
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.

from team.