How should I store contributor info ethically and practically?

Question

Background

I've started a FLOSS project and people are interested in helping out in different ways. I'm considering how to store information about these contributors

Information like for example:

• Contact information
  • Codeberg/GitLab username
• Technical knowledge
• Areas of interest and contribution

Question

I'd like do store information about the contributors

• in a privacy-minded way
• in a practical way
  • including allowing contributors to see each others info
  • and storing the information close to the project

My own thoughts about possible options

Option A: Public wiki page

One option I see is to store public information on a publicly available wiki page.

Information would then be available to everyone, but maybe that is fine if the information shared in the document was already public? I'm thinking of things like:

• chat-room user name (the chat room is public)
• what types of contribution the person wants to make (programming, testing, using and provide feedback, etc.)

Information that wouldn’t be stored:

• email

Option B: Privately stored, only accessible by me

This would respect privacy for sure, but would not be so practical for the reasons above (under the Question heading)

Option C: Invite

In previous projects I've been involved in, I've seen people storing this sort of information in a semi-private file that is shared by adding certain users (maybe in a Google Docs document, or hopefully a FLOSS option)

The problem I see here is that every user that is listed in the file would have to be contacted each time a new person is added, so it will not be very practical if there are many contributors to the project.

Answer 1

It's good to have a thriving community.

I'd advocate option D: Maintain a detailed readme file in the repository with a credits section, or a separate credits section with the contributors nickname in use, their real name (those who agree), maybe their e-mail (those who agree) and the areas of interest in which they work on. This can also include names of community moderators or whatsoever - they do not need to have an active code contribution to be listed there. E.g. I think what OpenTTD does works very well. I'd encourage new contributors in your usual communication / chat channels to add themselves to that list - or at least have them agree on or approve pull requests which change / add their info. Be generous with giving credits.

Having a invite-only group of core maintainers (e.g. in the discord and/or IRC and/or forums might be a good idea where you can discuss sensitive stuff (especially security). I'd not go around gathering more info officially about people than they publicly share in this credit readme or credits file.

Sure, you might exchange telephone numbers or contact in other than the usual channels within a small group, if there is interest. Yet I'd not formalize that but consider that private information which this other person gave me for personal use like within a group of friends. That happens rather naturally when the group dynamics are positive and e.g. there is the desire for a real-world get-together in whatever combination of subset of interested people.

This said, I'd advocate to keep public all discussions which can be public in your usual publicly-accessible dev channel. You might consider to have or not have logs, though to (not) make it a permanent record. Thus use your private dev channel only for what really needs to be discussed there. If you keep reviews, project discussions, patch considerations public, then you provide a way for interested people who are not yet contributors to see what happens. It allows that you gather there a community who might not all contribute actively code but still provide useful input, e.g. by giving feedback, providing detailed tests, or doing some reviews etc. And it allows people who so far were only listening to chime in and become contributors when there is actually a topic they are interested in and which they feel they are capable to contribute to. Thus guide your community with clear communication and give feedback of which features or directions are considered good and which you don't plan to consider (and why).

I know other projects which do not work as open as described here - and IMHO it shows in how active and community is; keeping it 'exclusive' seems mainly to serve the ego of those in power. It's the project's decision or the one of the maintainers, but IMHO it is not helpful in making the project grow and maintaining a vibrant community.

Answer 2

The answers given by others are correct.

Creating CONTRIBUTORS, AUTHORS and other files is common, especially in older projects like GNU or GNOME.

Most often, however, these files contain the people who have done the most. For example, GNU GCC stores maintainers of functions, ports, etc.

You can see a sample MAINTAINERS file for GCC here: https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=MAINTAINERS;hb=HEAD

see also the AUTHORS file for GTK: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/AUTHORS

Generally, when you host a project on GitHub or Gitlab, you are offered a contributor information service.

GitHub: https://docs.github.com/en/repositories/viewing-activity-and-data-for-your-repository/viewing-a-projects-contributors

GitLab: https://docs.gitlab.com/ee/user/project/repository/#repository-contributor-statistics

You can also write a program, e.g. a simple Python script, which will export the list of contributors from the Git repository and write it to a text file. You can check out this post on Stack OverFlow which shows how to do it with Git. https://stackoverflow.com/questions/9597410/list-all-developers-on-a-project-in-git

When it comes to storing detailed information (i.e. people's knowledge), I would not provide information about each person, but only about the most important ones. Then you can use README or other files including MAINTAINERS, AUTHORS etc.

Answer 3

Common practice in the open source community is to have a file CONTRIBUTORS in the root of the project's sourcecode directory that lists every contributor with all personal and contact information these contributors agreed to share with the world.

Keep in mind that contact information is personally identifiable information (PII), and as such sharing it with anyone without explicit permission is not just unethical but also illegal. That means that if you want to have some directory of contributors and share it among the team, then you need explicit consent of the people whose PII is in it. Which smart and privacy-conscious people won't give you, because they don't know who you are going to add to the project later and if they are comfortable with those people having their contact information.

If you want people to be able to contact each other even if you should not be around and your usual project communication infrastructure should fail, then I recommend to encourage (but not obligate) people to share contact information with any project members they trust to not misuse or mishandle that information.