Re: Choosing community-owned code to run on our community server.

st 27. 9. 2023 v 11:22 odesílatel Michiel de Jong <michiel@pondersource.com>
napsal:

> Hi fellow Solid community members,
>
> Since many years, we have a community pod server at
> https://solidcommunity.net.
> It is now time to switch the software it runs from NSS (Node.JS +
> JavaScript) to CSS (Node.JS + TypeScript).
>
> As you may know, the main repository
> <https://github.com/CommunitySolidServer/CommunitySolidServer> of the CSS
> code base and its issue tracker are under the full control of the CSS team
> at UGhent/imec, which is one of many institutions and stakeholders that
> come together in the Solid project (they will also be one of several W3C
> members coming together in the proposed Working Group; my employer Ponder
> Source being one of the others).
>
> Unfortunately, it has come to light a few years ago and again yesterday,
> that this particular code repository is not run in an inclusive way (see my
> forum post
> <https://forum.solidproject.org/t/migrating-from-nss-to-css/6856/5?u=michielbdejong>
> for the saddening details).
>
> Luckily, this is open source software and there are also other forks of
> the code, like the PDS Interop one
> <https://github.com/pdsinterop/community-server>. These generally have
> their own issue trackers, and their own decision mechanism for which
> contributions are accepted and which ones are not.
>
> So we have a choice. I think we should create a "community fork" (or use
> the existing PDS Interop one) of the Community Solid Server that *does*
> allow *all of us *to for instance propose experimental features we want
> to switch on on solidcommunity.net, which legacy features we do not want
> to be switched off, etcetera.
>
> As an example, I remember when I was working on Solid Web Monetization, it
> was easy to add an experimental endpoint
> <https://github.com/nodeSolidServer/node-solid-server/pull/1546> to the
> code running on solidcommunity.net, which I could then use for my demo,
> and discuss with other Solid community members, even though this feature
> eventually never made it into the spec.
>
> It's fun and useful if our community server can be used as a playground
> for features that are not in the spec. As a community, we should be
> empowered to do things like that on solidcommunity.net if and when we
> want to.
>
> So for solidcommunity.net, I think it is important that the code that
> runs there is maintained in a collaborative way, acknowledging all members
> of our community, their different reasons for being part of this project,
> their different skill sets and interests, and their different ways of
> contributing to the project.
>
> And of course not all PRs can always be merged, and not all feature
> requests can always be attended to. But even when a community member
> proposes a code change that the maintainers decide to reject, this
> contributor still has a right to be talked to in a welcoming and friendly
> way, and not see their contributions simply disappear from the issue
> tracker without explanation. So apart from the point about us as a
> community having control over the behaviour of the server, this is also
> sending a signal to ourselves, to the larger web standards community, and
> to the rest of the world, that (despite sometimes misconceptions to the
> contrary) the Solid project is run by a diverse and inclusive community,
> and all voices have a right to be heard here.
>
> We want our community to be a nice place for everybody! Only then can we
> make Solid a success.
>
> I therefore propose that when we switch solidcommunity.net from NSS to
> CSS, we use code from a repository that welcomes contributions from all
> members of the Solid community. This is a decision we can take as a
> community, which is why I'm posting this to the CG mailing list. The
> practical details of it can then be carried out by the Solid Team.
>

+1 to running code from a repository that welcomes contributions
(no-brainer, imho)

However, solid is better when there are multiple servers.

When I ran the original S.C. we ended up with 50,000 accounts.  That is
quite a large maintenance burden, if you really want to protect user data.

Question I have is whether there is a way to make signup invite only?  That
would help casual instances that want to help out, but dont have a lot of
maintenance resources.


>
> Thanks for reading this far; I'm curious how other people feel about this
> matter!
>
>
> Kind regards,
> Michiel de Jong
> https://www.w3.org/users/143305/
>