[opensource-wg] Call for contributions: Example credit policy

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.