docs(package.json): Add all contributors to package.json

[RichardLitt]

I got the following list of contributors by using name-your-contributors and the following jq commands:

cat contribs.json  | jq '.[][]' | jq 'if (.name | length) > 0 then {name: .name, url} else {name: .login, url} end' | jq -s . | jq unique

. This list reflects all of the contributors - either code or issue related, on GitHub or just in the commits. The list hadn't been updated in three years, so this list has now grown exponentially, but I don't see why we can't reference everyone. I'm very open to discussion on this.

Note: Unfortunately, my command line automatically ran the jq command. I hope I didn't just ping everyone, ever. My bad if so.

[hutson]

@RichardLitt the full contents of package.json are fetched when a package is downloaded on disk, and nock is downloaded 36k times a day, so what kind of additional bandwidth consumption are we talking here?

[hutson]

An alternative may be using a file in the repository that does not get automatically added to the npm package. Though Node is not an npm package, they are a good example of using a non-package.json file to maintain a list of everyone that has contributed to Node - AUTHORS.

[gr2m]

I like the idea of listing contributors, but I wouldn’t do it in the package.json for The same reason that @hbetts mentioned

[RichardLitt]

I agree with both of you. I've output the results into an AUTHORS.md file, and removed the Contributors field, which is outdated and which doesn't give attribution to people who've helped out on GitHub but who may not have contributed code. I think this is a much more elegant solution.

One thing I would suggest, before merging, would be to put the instructions for updating the Authors file somewhere for the future. What do you think?

[hutson]

One thing I would suggest, before merging, would be to put the instructions for updating the Authors file somewhere for the future. What do you think?

Is there an app that does that (submits a PR whenever someone new contributes to the project)?

[RichardLitt]

At the moment, no. That would be a good GitHub app to build, though. It would have to cache results and should do it once a month or so, as opposed to each time. This list comes from everyone who has every commented, reviewed code, opened an issue, or opened a PR, as well as committed.

[gr2m]

Shall we rename AUTHORS.md to CONTRIBUTORS.md? And I would suggest to not publish the file to npm, otherwise we have the same problem as with the big package.json file.
Could you add documentation on how to update the file and maybe create a "help wanted" issue asking if someone would like to build a bot to keep it up-to-date?

[RichardLitt]

I've added a note, and would be happy to make another issue. I've also ignored it from npm and renamed the file to CONTRIBUTORS.md. Look good? :)

[gr2m]

Can we hold off on this? I’m not sure if it’s a good idea. My concerns are:

1. It’s automated, so I’m not sure if people feel as recognized
2. I'm not sure if it catches all the contributions we want to recognize
3. It includes bots
4. The file is quite big
5. It increases the overhead for maintainers, another file we have to keep up-to-date. We could automate it, but that would be some extra effort

I agree that it would list contributors, but I’m not sure if that’s the right approach

[RichardLitt]

Those are very good points, @gr2m, thank you.

I started this PR and this general course of action because the list of contributors in the package.json was out-of-date. While it's easy for me to justify including everyone as the best solution, in truth I didn't realize how big the contributors list was going to be. Having gone through this process, I'm not sure that keeping a contributor's list makes sense for this repository, given the size of the list. However, I think it is the right thing to do. (I'll get to why in a bit.)

One easy solution to resolve the issue that precipitated this work would be to simply remove contributors in the npm manifest, as it is out-of-date and no longer representative of the contributors in this repository. Another would be to only count authors of commits. You can do this very easily with git authors. There may be some edge cases that aren't counted, but overall this is the easiest way to get some form of a contributors list, and it takes almost no effort.

Superficially, Name Your Contributors works best when you want to inflate metrics regarding the size of your community for marketing purposes, because it counts interactions that GitHub doesn't. It also can work when you want to raise up people who post comments and review PRs, but aren't very active in terms of submitting code themselves, by naming them and including them in the project. This can be useful for new projects who are keen to foster a sense of inclusion and community, at the cost of lowering the barrier of entry for being a 'contributor' and thus possibly diluting the term for cynics (for lack of a better word) who have more conservative definitions of that term. There is certainly a trade off - do we include everyone, or no one? Or somewhere in between?

An automatic approach can remove some effort by making it easier to grab all of the contributors who fall into certain categories. But it does remove the sense of contributors being curated, hand-picked, and special. So, is it worth automating? That's a good question.

I find this to be a really interesting discussion to have. I've been blunt above, because my focus in this PR has been sidestepping these issues, and I think it's suffered for that. Instead of merging immediately, I think we should step back and ask harder questions.

How do we, as a project, thank people who contribute? Does a file of contributors names make sense? Do people feel need this list to feel like they're part of the project's history, or do they have that sense, anyway? Does the list cost more in maintainer efforts than it gives back to the people on it? I don't know the answer to these questions.

However, I think it is important to thank people, and I think this file is a step towards that. I would personally include it.

A recent NY Times article pointed me to this new research, which says that people undervalue how appreciative people are for being thanked. While a bot (or GitHub App) may remove some of the feeling of appreciate, it's still set up by the maintainers of the repo, which shows that at some point, someone thought to go out of their way to thank members of the community. I think that this is worth doing.

In this PR, I've suggested casting a wide net and thanking everyone by building this file. I think the PR could be improved by adding these lines in the file:

This list has been generated to thank everyone here for their contribution. Nock wouldn't be what it is without the individuals who've given their time to it. In alphabetical order, here is a list of people who the maintainers think are worthy of being thanked publicly and permanently here.

That makes it clear that it's not just a random file, but part of a wider, systemic approach towards being grateful to community members for their work.

I don't think the effort of automating the list, or the size of the file, or the fact that it is automated are detractors enough to not go through with this effort. @gr2m, you also mention you're not sure it catches all contributions - what other types do you want to get?

Ultimately, you and the other maintainers may think more specific categories are called for when defining 'contributors', or you may want a hand-curated list. I can see where you're coming from. Is that what you want?

[RichardLitt]

I've added the paragraph I suggest to the Contributors file. What do you think?

[gr2m]

My main concern at this point is that generating the file is not automated and I fear we will easily forget about it.

To benefit from the appreciation we would also need to make sure that new contributors get notified if they get added to the list. Which Ideally we automate, too, e.g. by mentioning them in the commit message?

[RichardLitt]

Can we open another issue to automate it? For now, I think that that concern is holding up this PR. This PR is an improvement on the old information in the package.json, so I think it should stand on its own merits, not just how it will be six months from now.

Make sense?

[gr2m]

Automating it works for me. It would make a nice standalone issue that someone could work on. Hacktoberfest is around the corner, that could make a fitting issue

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue and add a reference to this one if it’s related. Thank you!

[nockbot]

🎉 This PR is included in version 10.0.2 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀