Hi all, Thanks for everyone's enthusiasm at the RIPE session about the open source project credit policy! While recovering from COVID I managed to put together a starting draft that included all of the suggestions I could remember.
Please edit the draft, via comments, suggestions, or direct edits: https://docs.google.com/document/d/1A4PVQ8iAZFPWySxMdY-EYDArII3BrlK_t70Cek6iwhc/edit?usp=sharing Please don't share this link outside this group but do feel free to share copies or solicit outside feedback. A copy of the current text is at the end of this email. Thank you in particular to Maria Matějka, Martin Winter, and Marcos Sanz for many excellent points and solutions. Valerie Link to video and slides: https://ripe87.ripe.net/programme/meeting-plan/os-wg/ Introduction The purpose of this document is to develop an example credit policy: a written description of how an open source software project gives credit for contributions. The problem: people disagree about credit for contributions Open source software projects receive a wide variety of contributions from many different people and organizations. Each contributor has their own assumptions and expectations for what kind of credit contributions should receive. When there is a mismatch between the credit a contributor expects to get and what they actually get, the project suffers. This is an especially important problem for open source software because the main motivation for contributing is often recognition and credit; when people don't receive what they expect, they are less likely to contribute in the future. Two concrete examples: How I got robbed of my first kernel contribution – Ariel Miculas Someone sends in a contribution that needs a little more work. The other contributors are too overworked to review the contribution. Some time later, another person fixes the same problem without ever seeing the first contribution. The first person says, "Hey, why did you rewrite my work without giving me credit?" Our solution: a written policy Our proposed solution to this problem is for each project to write down and publish a formal credit policy (or contribution policy, or anti-plagiarism policy - whatever name seems best). This policy describes what kind of credit and acknowledgement contributors can expect. It also serves as a guide for decision-making for project leaders when they run into more complex problems associated with credit. The end result is that contributors are more likely to contribute to projects with matching credit policies, and project leaders spend less time arguing with contributors or trying to decide how to handle edge cases. The example policy we are writing in this document includes a variety of different ways to assign credit, depending on the project's goals and priorities. Projects can copy parts of the example policy and edit as necessary, or create their own policies from scratch. Scope of a credit policy The policy should cover all types of contribution: documentation, code, tutorials, event organization, testing, design , etc. It should focus primarily on cases in which multiple people or organizations are collaborating on a contribution, when people disagree about who gets credit, and other situations in which credit is less clear. It does not attempt to resolve any legal issues around IP or copyright; that is the domain of contributor agreements, licenses, and other documents. Credit for this policy If you contributed to this policy, please add your name here. We will decide how to credit the contributors as we develop this policy. Valerie Aurora Maria Matějka Martin Winter Marcos Sanz Fair warning: the most successful policies are often the ones with no attribution since people often reject them when their provenance is called out. Ironic, huh? Real-world examples Here are few examples of situations that a credit policy should address: Someone sends a first draft (of a document, code, HTML, etc.). A second person makes significant edits to it. Someone sends a first draft. Another person entirely rewrites it from scratch. Someone sends a contribution. The contribution does not improve the project. Someone sends a contribution but does not complete the "sign-off" or other process step that the project requires. The first reminder goes unanswered for several days. Someone sends a first draft. It fixes a real problem but in a way that is unacceptable for inclusion. They do not respond or are unwilling to make the necessary changes for inclusion. Someone sends a contribution but no one else in the project notices. Later another person makes a similar contribution and gets credit for it. Someone sends a somewhat useless contribution. When you look at their contribution history, you see them sending a lot of useless contributions to other projects. Someone sends a contribution that seems suspicious. When you look at their contribution history, they seem to have rewritten a lot of other people's contributions. Someone sends a lot of tiny separate trivial contributions. They aren't actually making much difference to the project, but if you accept them all it will look like they should have credit for half the project. Someone sends a contribution. For whatever reason, the contribution does not actually seem to be motivated by a desire to improve the project. Someone sends a contribution but a project leader hates the style. Someone sends a contribution and it seems kind of mean-spirited. Policy structure The policy should consist of the following parts: Preamble describing the overall goals and philosophy of the project's credit policy High-level description of how credit is assigned for contributions List of specific situations with step-by-step instructions on what to do in each one How to contact the project if someone thinks that credit has not been given correctly Instructions for people implementing the credit policy, including what to do in difficult situations The last part does not need to be published but can be. Preamble options The preamble describes the overall philosophy of your project towards contributions: what kind of contributions you want to encourage, what kind of contributors you want participating, what your priorities are when it comes to different aspects of quality or productiveness. Your preamble should discourage the kind of contributions you don't want and encourage the kind of contributions you do want. Here are some possible preambles that prioritize different goals. We welcome a broad range of contributions from as many contributors as possible We encourage contributions from as many contributors as possible, and strive to make contributing easy and rewarding. We prefer to guide original contributors through the process of making necessary changes to any contributions, and reward mentoring and review. When a contribution is the combined effort of several people, we prefer to give primary credit to newer contributors. We give credit generously for all of the work that goes into making this project a success, including testing, review, debugging, mentoring, operations, documentation, and similar work. We welcome contributions that do not need much work We encourage contributions but our existing contributors have limited time to mentor or guide new contributors. When a contribution needs changes, existing contributors will usually make any necessary changes themselves rather than working with the original contributor to make the changes. However, we strive to give primary credit to the original contributor whenever possible. We especially encourage contributions that make it easier for new contributors to become productive without direct mentoring, such as documentation, tutorials, refactoring, tests, and similar. We accept outside contributions rarely Our priority is quality of contributions and architectural cohesion. We prefer contributions from existing contributors who are already familiar with our processes and standards, and are carrying out the architectural vision of our leaders. We do not mentor or guide new contributors. When existing contributors rewrite, reuse, or are inspired by contributions from new contributors, it is up to the existing contributor to decide how or if to credit the original author. We prioritize speed of development Our priority is speed of development. We reward contributors who send working contributions quickly. We prefer to give credit to the person who sends the first acceptable form of a contribution rather than the original contributor. Only bug fixes welcome [YOUR DRAFT HERE] My personal project subject to my personal whims [YOUR DRAFT HERE] Our corporate project not open to outside contributions [YOUR DRAFT HERE] Our research project not open to outside contributions [YOUR DRAFT HERE] [YOUR PREAMBLE HERE] Credit assignment options Here are a selection of possible rules for assigning credit. You should choose the ones that encourage the behavior you describe in your philosophy. For example, if you want to encourage new contributors, choose rules that give credit more generously to new contributors than existing ones. If you want existing contributors to have strong control over the project, choose rules that give credit more generously to people who edit or rewrite contributions. Note: don’t get too wrapped up in who “really wrote a contribution.” Most contributions are a collaborative effort by multiple people and it would be impossible to give credit to every single person who made a one line contribution to your project possible. Instead, focus on what behaviors you want to reward and which ones you want to discourage, and be creative about how you do that. If a contribution includes substantial work from multiple authors, we will give primary credit to the least experienced contributor. If we need to rewrite a contribution, we will give primary credit to the author of the first version and secondary credit to the person rewriting it. If we need to rewrite a contribution, we will give primary credit to the person rewriting it and secondary credit to the author of the first version. If we need to rewrite a contribution, we will work with the original author to make the necessary changes for as long as they respond in good faith and in a timely manner. In any case, the original author will get primary credit. The project leaders are the sole authority on who gets credit and will assign it to no one, to themselves, or to others as they see fit. [YOUR SUGGESTION HERE] Please make it easy for us to accept and credit your contribution! Here are the steps to take to get the most credit for your work: [CHOOSE APPLICABLE] Include “Signed-off-by: [YOUR NAME]” Agree to the CLA Follow the instructions in CONTRIBUTING Respond to requests for changes within N days Cooperate in good faith with our requests for changes If you do not want to make changes, please tell us as soon as possible [YOUR SUGGESTION HERE] If for some reasons you can’t or won’t make necessary changes to your contribution, we will [CHOOSE ONE OR MORE AND EDIT TO FIT] Reject your contribution and take no further action Incorporate your original contribution as is, then make a second change with any edits Incorporate your contribution along with any necessary edits with primary credit to the newest contributor, with a link in the change message to your original contribution on our mailing list or other archive of original contributions (e.g. a directory in the source code, a section of the wiki, etc.) If you did not [sign off, agree to the CLA, other necessary process step], we will rewrite from scratch and include a link to the original contribution in the change message How we give credit: For commits to a repository, the primary author is the commit author. For reviews, editing, testing, debugging, or reporting directly related to a specific contribution, we add a line in the change message such as “Reviewed-by” or “Edited-by”. For contributions that are not specific to an individual change, such as hosting, DevOps, DevRel, issue curation, etc, we will add your name to [LIST AND LOCATION OF PUBLICATION]. To be added to this list, please [INSTRUCTIONS]. [Suggestion: include an option for extremely minor contributions.] [YOUR SUGGESTION HERE] We reserve the right to not grant credit when it seems detrimental to our project. For example, if someone requests credit to a name that is obscene or harmful, or if they are spamming multiple projects with minor contributions, or if interacting with a contributor is demoralizing to other contributors. Correcting mistakes in credit Sometimes we make a mistake in how we give credit. In this project: [CHOOSE FROM FOLLOWING] Once credit had been given, we will not go back and correct it. We will correct mistakes in credit attribution for up to [TIME PERIOD] after credit has been given. We will correct mistakes in credit at any point. [YOUR SUGGESTIONS HERE] Reporting problems with credit If someone has not given credit correctly, please contact [CONTACT INFORMATION - COULD BE CODE OF CONDUCT COMMITTEE] and include any relevant information. [NAMES] will review your report and take any action they deem appropriate, including but not limited to updating the credit information, warning the person who did not follow the credit policy, no longer accepting their contributions, or forwarding the complaint to the community code of conduct committee. _______________________________________________ opensource-wg mailing list opensource-wg@ripe.net https://lists.ripe.net/mailman/listinfo/opensource-wg To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/opensource-wg
