Hi everyone,
Hope to see you at FOSDEM. We (NLnet/NGI0 consortium) have made a list
of talks and activities that are related to NGI Zero at FOSDEM, OFFDEM
and Fringe.
You can find it here: https://nlnet.nl/events/20240203/index.html.
We also have a stand in Building K, where FSFE will also have one. Come
by and hello!
--
Kind regards,
Tessel Renzenbrink
Communication officer
NLnet.nl
Dear RIPE Open Source WG community,
I'm pleased to inform you about a new initiative involving OpenWrt,
spearheaded by John Crispin.
This project, named OpenWrt One, is focused on creating a specialized
wireless networking device aimed at open source software enthusiasts.
It emphasizes educational aspects, compliance with FOSS licenses, and
a rich array of networking features. You can find out more in these
threads:
https://lists.openwrt.org/pipermail/openwrt-devel/2024-January/042018.htmlhttps://lists.openwrt.org/pipermail/openwrt-adm/2024-January/002479.html
Additionally, a portion of the sales revenue from this device will
directly support the OpenWrt project. For more detailed information
and to participate in discussions related to this topic, please
consider subscribing to the relevant OpenWrt mailing lists [1].
Take care,
Luka
[1] https://lists.openwrt.org/mailman/listinfo
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?
https://docs.google.com/document/d/1A4PVQ8iAZFPWySxMdY-EYDArII3BrlK_t70Cek6…
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:
https://www.ripe.net/participate/ripe/wg/active-wg/os
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.
