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

Hello all from the solid community and Michiel and Melvin.

I will not answer in a detailed indented way but write my first impression  
and some general thoughts.
Not good to hear how they answered to you, Michiel and I strongly support  
you and am thankful for Melvin's support.

++ for community-owned code.

I know you are highly professional and I support the consideration of the  
code of conduct committee.
Open Source is not just the basic codebase but also a point of view, a  
mindset, a philosophy that tries to act for the common good.

I'm a baby coder but I will provide my best efforts to support our  
community with

a) solidweb.org (NSS) as long as necessary
b) solidweb.me (CSS) as a clone from the recipes repo.

maybe we can gather further feedback. for my part I try to provide useful  
service and I think the reaction of them is inappropriate.

bottom line: we should make sure our software and our services and our  
development follows the open minded and not discriminative and helpful  
path.

@ewingson

Am 27.09.2023, 14:53 Uhr, schrieb Melvin Carvalho  
<melvincarvalho@gmail.com>:

> 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).
>>
>
> Hi Michiel, as the person that started the solid community initiative,  
> and
> led it for a quarter of a decade, I have some views on this.
>
>
>>
>> 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).
>>
>
> First, I'm incredibly sorry that you were treated this way.  Phrases such
> as "Go steal other people’s time" are completely unacceptable.  The whole
> message was tough reading.
>
> Please tell me that the code of conduct committee are looking at this?
>
>>
>>
>> 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.
>>
>
> +1 to open source
>
>
>> 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.
>>
>
> It's doable although I started the solid community effort specifically  
> for
> node solid server.
>
>
>>
>> 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.
>>
>
> +1
>
>
>>
>> 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.
>>
>
> I still own the original domain solid.community which I have always said
> could be donated to the community effort.  It was unfortunate that during
> the covid years I got sick.
>
>
>>
>> Thanks for reading this far; I'm curious how other people feel about  
>> this
>> matter!
>>
>
> Strongly support!
>
>
>>
>>
>> Kind regards,
>> Michiel de Jong
>> https://www.w3.org/users/143305/
>>


-- 
Matthias (@ewingson)

Received on Wednesday, 27 September 2023 14:05:56 UTC