search

solid / process

A definition of the culture around how decisions are made about Solid and a record of how this has changed over time
MIT License
110 stars 45 forks source link

Add guidelines for repository inclusion #276

Open RubenVerborgh opened 2 years ago

RubenVerborgh commented 2 years ago

As discussed by the Solid Team, the GitHub organization github.com/solid will in the near future only contain repositories that are managed by the Solid team.

This pull request adds those guidelines into the process.

kjetilk commented 2 years ago

I apologize for not responding sooner. The team meeting is at a time when I can rarely if ever make it.

While I strongly support cleaning up the repo of stuff that only serves to confuse people, I wonder if this takes it too far. I wonder if it would be better to actually have a team approval process, and not put that bar too high. If I understand the proposal, this would also move stuff like mashlib out of there, which has been there since the dawn of ages.

There is value to having stuff in the same organisation, it makes it easier to maintain a group of writes and stuff like that to help review.

RubenVerborgh commented 2 years ago

If I understand the proposal, this would also move stuff like mashlib out of there, which has been there since the dawn of ages.

More specifically, there would be a separate SolidOS (or similar) organization that groups all of the Mashlib things together, so there is a better overview. (And note that redirects will be put in place.)

bourgeoa commented 2 years ago

As suggested I repost here.

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

RubenVerborgh commented 2 years ago

(Thanks @bourgeoa, will repeat and extend my answer here as well for completeness of the discussion.)

This imply removing all solid history and relation between implementation and specification.

I think rather we should set up better relations. It would be good to maintain a list of implementations of the specifications. The current github.com/solid only has a very partial list.

Would the additional proposal at https://github.com/solid/team/issues/23 maintain that relation?

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

We would keep namespace and solidcommunity.net. Namespace (if it is the repo I think it is) because it fits "specification documents"; solidcommunity.net because "materials for Solid project websites".

We would give auth libraries, NSS, Mashlib, tests their own spaces, as they are opinionated implementations of the specification. We should still link to all of them (see above).

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 linking can help as well.

Does solid/team do not cover some form of community management ?

Not at the moment, it seems; whether or not code is on github.com/solid seems to be random at the moment.

Does solid-contrib reflects the community involvement ? Be it university contributions or individuals ... ?

It could; however, I don't see a need to centralize.