<html><head></head><body><div dir="auto">Hello Valerie and others, I drafted a full new section about how to actually name people correctly. (Thanks to Valerie for indirectly pointing at this issue.) The text is probably too sarcastic at some places, reflecting some of my experience (mostly) outside IT. Feel free to smoothen the rough edges. Also feel free to continue working on it from other perspectives which I may have missed when typing this on my phone while commuting. Have a nice day, night, fortnight or whatever you wish! Maria </div> <div class="gmail_quote"><div dir="auto">On 8 January 2024 20:28:41 CET, Valerie Aurora <val@valerieaurora.org> wrote:</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <pre class="k9mail"><div dir="auto">Hi all, Thanks for the useful feedback on the first draft of the credit policy! Thank you especially to Maria, who wrote many useful additions, all of which are now integrated. My plan is to get one more round of comments on this within the OS wg, then do a public call for comments, then make an initial release. Please review the current version, included inline below and in the Google Docs link (suggestions for better co-editing tools welcome). In addition to Maria's contributions, I made one additional change to the document: a proposed credit and license section using Creative Commons Zero 1.0 Universal license: "This credit policy by RIPE NCC Open Source Working Group and lead authors Valerie Aurora, Maria Matějka (project BIRD, CZ.NIC), Martin Winter, and Marcos Sanz is marked with CC0 1.0. If you create a derivative work, we request but do not require that you voluntarily give credit to the above contributors." This is about reducing friction. The CC BY-SA 4.0 license would require crediting every person who ever contributed by name or risk legal problems, which often causes people to decide it is too much trouble to use. CC0 would allow people to use their judgement on who to credit, without worrying about legal requirements. As such, it is in the spirit of the credit policy itself. My personal view is that the kind of person adopting a credit policy will likely give credit voluntarily. Thoughts? <a href="https://docs.google.com/document/d/1A4PVQ8iAZFPWySxMdY-EYDArII3BrlK_t70Cek6iwhc/edit">https://docs.google.com/document/d/1A4PVQ8iAZFPWySxMdY-EYDArII3BrlK_t70Cek6iwhc/edit</a> Valerie Credit policy for open source projects - working draft Introduction The problem: people disagree about credit for contributions Our solution: a written policy Scope of a credit policy Credit for this policy Real-world examples Policy structure Preamble options We welcome a broad range of contributions from as many contributors as possible We welcome contributions that do not need much work We accept outside contributions rarely We prioritize speed of development Only bug fixes welcome My personal project subject to my personal whims Our corporate project not open to outside contributions Our research project not open to outside contributions [YOUR PREAMBLE HERE] Credit assignment options Correcting mistakes in credit Reporting problems with credit 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. This project was created and led by many members of the RIPE NCC Open Source Working Group: <a href="https://www.ripe.net/participate/ripe/wg/active-wg/os">https://www.ripe.net/participate/ripe/wg/active-wg/os</a> 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, both the project and the people around it suffer. 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. This also applies for upstreaming local changes. Even though the main motivation may seem to be some reduction of future maintenance costs, all the parties benefit from proper crediting, e.g. when some changes in the contributed code are proposed in future and consulting with the original authors is handy. 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 (project BIRD, CZ.NIC) 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 comments with ideas leading the original sender to incorporate them in the second draft. 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 contribution which is actually valuable to the project but directly conflicts with other project plans and aligning it means to actually rewrite the contribution completely. 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. Someone sends a complaint which gets ignored or rejected. Later, the maintainers find themselves fixing the subject of the complaint anyway. 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. Note: The more contributions you want to encourage, the more documentation you actually need. It’s hard to welcome a broad range of contributions with lack of programmer’s documentation and proper open future planning, including upfront disclosure of (or hosting public discussions on) architectural decisions, to guide the contributors even before they actually start working. 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. All people and companies involved in the contribution get credits equally. If multiple contributors submit similar work, the accepted author gets primary credit and every other contributor, whose work was thus rejected, gets secondary credit. [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]” Put your name into the AUTHORS file 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, 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 has 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. Credit and license This credit policy by RIPE NCC Open Source Working Group and lead authors Valerie Aurora, Maria Matějka (project BIRD, CZ.NIC), Martin Winter, and Marcos Sanz is marked with CC0 1.0. If you create a derivative work, we request but do not require that you voluntarily give credit to the above contributors.<hr>opensource-wg mailing list opensource-wg@ripe.net <a href="https://mailman.ripe.net/">https://mailman.ripe.net/</a> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: <a href="https://mailman.ripe.net/">https://mailman.ripe.net/</a> </div></pre></blockquote></div><div dir="auto"><div class='k9mail-signature'>-- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</div></div></body></html>