Proposal: ensure the Solid GitHub organization only contains working code and up-to-date documents
Closed this issue · 4 comments
What is wrong this proposal? It is using a change of URI to change the status of something. That no way to run a restaurant. The way to work is to use metadata to express the status of things: lists and tags, typically.
It is a fallacy that a "one-time change" will be what will be needed. Things like
- actively used code
- old code
- people's personal projects
- shared projects
- placeholders for future work
are in fact not constants but functions of time. Tempting though it is to to make different github orgs for them, we would have to review the status of them very frequently -- particularly code that work our doesn't that changes very fast. Do you want a CI process which switches it to a different organization until the tests pass again?
It would fine to have the solid process in a different org to code and specs, I guess. But code and specs overlap, as canonical implementations and tests are very close to specs.
I counter-propose that we make and curate lists in turtle of the status of the repos, and use that to drive lists on the solid project website. The solid org on github can drive people to that.
Yes, there are things we can archive I guess, but what about things I have put there as placeholders for people to look at, things people have picked up and need help with, things which work, things which broke, things which have been fixed, things which we will never fix but we don't know that now...
Meanwhile we have keywords like running code which github turns into lists like https://github.com/search?q=topic%3Arunning-code+org%3Asolid&type=Repositories
Counter propose we continue to use metadata to solve the problem, not changing URLs of things.
@timbl - If you point me to existing github lists and/or the metadata terms that would be useful, I can make a generator for these repos the way I did for people at https://jeff-zucker.solidcommunity.net/sp/ which is entirely generated from RDF.
Generally I think this is a good direction to go, so long as the people who do want to find / work on any repositories that are moved can find them, and that shouldn't be a problem given automatic github redirects, plus any additional guidance, documentation, metadata we provide above and beyond that.
I wonder whether solid-contrib would be needed, or if that wouldn't be something that could just live under a user account of the individual working on it, or in an organization they standup, until it is submitted / approved to live under the solid org?
@RubenVerborgh I think this is a great proposal; you're right that the current arrangement causes confusion for newcomers.