Add contributors document with sections

[RubenVerborgh]

Alternative to #1055. Difference: this version organizes contributors in sections to distinguish current code contributors from past code contributors, and to list non-code contributors (issues, support, testing, …).

---

This PR aims to address #1053 by:

• adding a CONTRIBUTORS.md document
• adjusting LICENSE.md and package.json to explicitly include names of code contributors
• adjusting README.md to link to these

May I ask for your feedback regarding:

• the wording used
• the people included on those lists
• anything else you want to change or add

I emphasize that my effort is not a value judgement whatsoever; I arrived a long time after the Solid project started, so it is very likely that I have not included sufficient people in those lists. Please see this PR as a template, not a gospel.

Thanks for your help.

Closes #1053.

[steven-tomlinson]

If I understand this correctly, the community members who have actually contributed to the Solid-Platform will not be explicitly acknowledged for their contributions, except in a very general nebulous way. Kind of sucks.

[RubenVerborgh]

If I understand this correctly, the people who have actually contributed to the Solid-Platform will not be explicitly acknowledged for their contributions

Fortunately, you're not understanding this correctly 🙂
Not acknowledging contributors can never be anyone's intention.

except in a very general nebulous way.

Please let me know what you would like, and let's make it happen. Concrete and actionable ideas are very welcome; this PR came out of such an idea.

[csarven]

Thank you Ruben! Just a few comments:

I think a flat list of contributors may be preferable in that it doesn't make a hard divisions on how people contribute - people do shift around over time and work on stuff from different angles. It'd also be easier to maintain that list instead of trying to determine where someone fits in at any point in time.

How a contribution materialises is not always straight-forward, and often requires multiple people involved. For instance, why would code committers have rights or license of the work just because they happen to push commits? That may be a bit narrow perspective in that such arrangement almost signals as if the project is set by those that commit - and leaves people that architect, design, or iterate through the ideas/issues behind - which almost always comes much before the actual "code". We generally reach a rough consensus on what we need, and then proceed with the code, right? So, IMHO, these things should be balanced as much as possible. Whatever a "significant" contribution entails, I would suggest that each person's contribution to the project is seen as an equal part of the bigger picture. After all, we're all investing towards the same end.

[RubenVerborgh]

@steven-tomlinson Is your question to add your name explicitly to CONTRIBUTORS.md based on your commits to node-solid-server?

[RubenVerborgh]

I think a flat list of contributors may be preferable

Can we vote on this comment with 🎉 (flat) and 😄 (sectioned) to indicate preference?

I will reply to your points in follow-up comment with my preference.

[steven-tomlinson]

Thanks for responding, I guess my misunderstanding is if this will subsume the "contributors" section in the project statistics but I realize that it is not the intention now.

[dmitrizagidulin]

👍

[megoth]

This looks good to me ^_^

[RubenVerborgh]

Then this comes down to setting the bar for "significant" code contributions in order to give/share rights. At the very least, know how to measure it. Number of commits? Frequency? Duration? Difficulty? Importance? Something else? All? If that can be documented up front, that'd be great.

Agree, and happy for advise on that.
Here is the very ad-hoc process I have followed to kickstart this:

• Set Tim as project lead, because he is the Solid idea initiator, first author, and author in package.json.
• "code contributors" was determined by going to https://github.com/solid/node-solid-server/graphs/contributors, then realizing this information is outdated because it only reflects the master branch and we are currently on release/5.0.0. I obtained similar numbers from the command line with git shortlog -sn --no-merges release/v5.0.0 -- "**/*.js". That's when I also noted that Martin Martinez Rivera was missing from the GitHub stats, probably because the email address he uses for commits is unknown by GitHub. (Lesson learned: use the command line for these things.) When doing this, a clear split emerges: a long tail of incidental contributors (whose work I do value) with less than 10 commits (between 1 and 7), and people with several dozens of commits (between 68 and 290). The latter have been included as code contributors.
• Of those code contributors, I hand-picked the 3 people I know are currently working on the server. That could be automated as well I presume.
• Project contributors were picked by checking people who had created multiple issues. I also manually added Kingsley because of his extensive testing of NSS.

The issue is however those that commit code are in a sense rewarded by having rights - at least officially - meanwhile, any work that leads to the commits or even improvements afterwards, in any shape or form is not rewarded on the same grounds. I don't find that to be fair to anyone

There's multiple sides to fairness here. Writing code is an act through which you, legally, can exercise copyright on what you have written. Contributions that are not preserved in the git repository, are not protected by such laws in the scope of that repository. That's why it makes sense to distinguish in my opinion.

In fact, by including people who have contributed valuable work through issues, we acknowledge that there is a gap in copyright that does not cover these things, while at the same time keeping it separate from things that are covered.

if this is going to come down to the technicalities of law

It does not; you asked for my reasoning and I explained it.

I just think that speaks volumes and sets a certain tone to the project. It kind of already has.

That hurts, Sarven. I made this PR to help you and address your concerns, because I believe it is right.
There's no need to turn my well-intended actions into a reflection of the community, because they are not. You and others—rightly—asked for recognition for non-code contributions. As I said, happy to listen to other opinions, but I find your remarks very sharp as a reply to my making an explicit section to thank non-code contributors.

I will make another PR with a flat list, and let @timbl as a project initiator decide.

[RubenVerborgh]

Alternative PR without sections in #1055.

[RubenVerborgh]

Other possibilities:

• https://github.com/all-contributors/all-contributors
• https://github.com/caolan/nodeunit/blob/master/CONTRIBUTORS.md
• https://salsa.debian.org/hpc-team/singularity-container/blob/master/CONTRIBUTORS.md
• https://hz.mit.edu/git/catsoop/catsoop/src/branch/master/CONTRIBUTORS.md

[csarven]

Ruben, thanks for the breakdown on the ad-hoc process. Sounds pretty reasonable to me. I apologise for apparently coming across sharp or possibly even unappreciative. On the contrary, I immensely appreciate your time and attention on this, and the last thing I want to do is to insult you or the community in any way! I'll admit that I didn't express myself well, so I won't press further. If of any interest as a fun mental activity, we can perhaps discuss next time in person. I don't feel strongly about flat/section lists, so this 1054 or 1055 will equally serve well. Whichever works best for everyone. Thanks!

[RubenVerborgh]

No worries, then we'll let @timbl decide which one he thinks is more helpful.

I think it's very important that we list non-code contributors; the value they bring is huge, and I don't see too many other repositories do that. This repository would definitely not be what it is without all of the feedback, criticisms, and suggestions.

[kjetilk]

I don't have any strong opinions on the matter. I acknowledge it is difficult, for the reasons @csarven outlines, since by various laws, there is a significance threshold for code contributions, which is hard to set clear technical rules for, and then they occupy a special place.

I think it is therefore also important to acknowledge non-technical contributions. We just have to work through it to find a good place to be in.

[dan-f]

#1055 (comment)

[timbl]

Suggest add Amy Guy as project conhtributor

[RubenVerborgh]

@timbl I have been in touch with @rhiaro during the creation of this PR, and have asked whether she wanted to be listed. She has approved this PR in its current state (see above).

[RubenVerborgh]

@timbl After your comment, @rhiaro has reached out to me with an indication that she would like to be added, and so I did in 36fe246.

Now I'm just waiting for @dan-f to confirm.

@solid/core @solid/collaborators Please let me know if anyone else should be added. Even if we forget here, we still can add people later on. Also a reminder that there is no value judgement from my side whatsoever; if you feel you need to be added, you probably need to be, so let me know and I will (or write to the branch yourself).

[dan-f]

👍 from me, after on and offline discussion

[RubenVerborgh]

@timbl We have heard back from all parties now. Could you please choose between this PR (#1054) or the non-sectioned alternative (#1055), and approve and/or merge? Thanks.

[RubenVerborgh]

@timbl We have heard back from all parties now. Could you please choose between this PR (#1054) or the non-sectioned alternative (#1055), and approve and/or merge? Thanks.

[RubenVerborgh]

In private communication, @timbl expressed his preference for this more specific list, so I will merge it.

Thanks all for your help and feedback, and please do not hesitate to suggest adding more names of contributors.

Issue was addressed.