Sample Translation Collaborative Code Construction Contract (C4)

Cooperation - Lyncconf Games, CC BY 2.0

Pieter Hintjens

Code of Conduct (22/C4.1)

License

Copyright (c) 2009-2015 Pieter Hintjens.

This Specification is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

This Specification is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, see .

Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Goals

C4 is meant to provide a reusable optimal collaboration model for open source software projects. It has these specific goals:

  • To maximize the scale and diversity of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;
  • To relieve dependencies on key individuals by separating different skill sets so that there is a larger pool of competence in any required domain;
  • To allow the project to develop faster and more accurately, by increasing the diversity of the decision making process;
  • To support the natural life cycle of project versions from experimental through to stable, by allowing safe experimentation, rapid failure, and isolation of stable code;
  • To reduce the internal complexity of project repositories, thus making it easier for Contributors to participate and reducing the scope for error;
  • To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities.
Design
Preliminaries
  • The project SHALL use the git distributed revision control system.
  • The project SHALL be hosted on github.com or equivalent, herein called the "Platform".
  • The project SHALL use the Platform issue tracker.
  • The project SHOULD have clearly documented guidelines for code style.
  • A "Contributor" is a person who wishes to provide a patch, being a set of commits that solve some clearly identified problem.
  • A "Maintainer" is a person who merges patches to the project. Maintainers are not developers; their job is to enforce process.
  • Contributors SHALL NOT have commit access to the repository unless they are also Maintainers.
  • Maintainers SHALL have commit access to the repository.
  • Everyone, without distinction or discrimination, SHALL have an equal right to become a Contributor under the terms of this contract.
Licensing and Ownership
  • The project SHALL use a share-alike license, such as the GPLv3 or a variant thereof (LGPL, AGPL), or the MPLv2.
  • All contributions to the project source code ("patches") SHALL use the same license as the project.
  • All patches are owned by their authors. There SHALL NOT be any copyright assignment process.
  • The copyrights in the project SHALL be owned collectively by all its Contributors.
  • Each Contributor SHALL be responsible for identifying themselves in the project Contributor list.
Patch Requirements
  • Maintainers and Contributors MUST have a Platform account and SHOULD use their real names or a well-known alias.
  • A patch SHOULD be a minimal and accurate answer to exactly one identified and agreed problem.
  • A patch MUST adhere to the code style guidelines of the project if these are defined.
  • A patch MUST adhere to the "Evolution of Public Contracts" guidelines defined below.
  • A patch SHALL NOT include non-trivial code from other projects unless the Contributor is the original author of that code.
  • A patch MUST compile cleanly and pass project self-tests on at least the principle target platform.
  • A patch commit message SHOULD consist of a single short (less than 50 character) line summarizing the change, optionally followed by a blank line and then a more thorough description.
  • A "Correct Patch" is one that satisfies the above requirements.
Development Process
  • Change on the project SHALL be governed by the pattern of accurately identifying problems and applying minimal, accurate solutions to these problems.
  • To request changes, a user SHOULD log an issue on the project Platform issue tracker.
  • The user or Contributor SHOULD write the issue by describing the problem they face or observe.
  • The user or Contributor SHOULD seek consensus on the accuracy of their observation, and the value of solving the problem.
  • Users SHALL NOT log feature requests, ideas, suggestions, or any solutions to problems that are not explicitly documented and provable.
  • Thus, the release history of the project SHALL be a list of meaningful issues logged and solved.
  • To work on an issue, a Contributor SHALL fork the project repository and then work on their forked repository.
  • To submit a patch, a Contributor SHALL create a Platform pull request back to the project.
  • A Contributor SHALL NOT commit changes directly to the project.
  • If the Platform implements pull requests as issues, a Contributor MAY directly send a pull request without logging a separate issue.
  • To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere.
  • To accept or reject a patch, a Maintainer SHALL use the Platform interface.
  • Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 1-2 days).
  • Maintainers SHALL NOT make value judgments on correct patches.
  • Maintainers SHALL merge correct patches from other Contributors rapidly.
  • The Contributor MAY tag an issue as "Ready" after making a pull request for the issue.
  • The user who created an issue SHOULD close the issue after checking the patch is successful.
  • Maintainers SHOULD ask for improvements to incorrect patches and SHOULD reject incorrect patches if the Contributor does not respond constructively.
  • Any Contributor who has value judgments on a correct patch SHOULD express these via their own patches.
  • Maintainers MAY commit changes to non-source documentation directly to the project.
Creating Stable Releases
  • The project SHALL have one branch ("master") that always holds the latest in-progress version and SHOULD always build.
  • The project SHALL NOT use topic branches for any reason. Personal forks MAY use topic branches.
  • To make a stable release someone SHALL fork the repository by copying it and thus become maintainer of this repository.
  • Forking a project for stabilization MAY be done unilaterally and without agreement of project maintainers.
  • A stabilization project SHOULD be maintained by the same process as the main project.
  • A patch to a stabilization project declared "stable" SHALL be accompanied by a reproducible test case.
Evolution of Public Contracts
  • All Public Contracts (APIs or protocols) SHALL be documented.
  • All Public Contracts SHOULD have space for extensibility and experimentation.
  • A patch that modifies a stable Public Contract SHOULD not break existing applications unless there is overriding consensus on the value of doing this.
  • A patch that introduces new features to a Public Contract SHOULD do so using new names.
  • Old names SHOULD be deprecated in a systematic fashion by marking new names as "experimental" until they are stable, then marking the old names as "deprecated".
  • When sufficient time has passed, old deprecated names SHOULD be marked "legacy" and eventually removed.
  • Old names SHALL NOT be reused by new features.
  • When old names are removed, their implementations MUST provoke an exception (assertion) if used by applications.
Project Administration
  • The project founders SHALL act as Administrators to manage the set of project Maintainers.
  • The Administrators SHALL ensure their own succession over time by promoting the most effective Maintainers.
  • A new Contributor who makes a correct patch SHALL be invited to become a Maintainer.
  • Administrators MAY remove Maintainers who are inactive for an extended period of time, or who repeatedly fail to apply this process accurately.
  • Administrators SHOULD block or ban "bad actors" who cause stress and pain to others in the project. This should be done after public discussion, with a chance for all parties to speak. A bad actor is someone who repeatedly ignores the rules and culture of the project, who is needlessly argumentative or hostile, or who is offensive, and who is unable to self-correct their behavior when asked to do so by others.

Source.

Dutch Translation

Gedragscode (22/C4.1)

Licentie

Copyright (c) 2009-2015 Pieter Hintjens.

Deze specificatie is vrije software; herdistributie en/of het aanbrengen van wijzigingen is toegestaan onder de voorwaarden vermeld in de GNU General Public License die is gepubliceerd door de Free Software Foundation - versie 3 van de licentie of desgewenst een latere versie.

Deze specificatie wordt verspreid in de hoop dat ze nuttig zal zijn, echter ZONDER ENIGE GARANTIE; zelfs zonder de impliciete garantie van VERKOOPBAARHEID of GESCHIKTHEID VOOR EEN SPECIFIEK DOEL. Raadpleeg de GNU General Public License voor meer details.

Samen met dit programma moet je een kopie van de GNU General Public License hebben ontvangen; zie als dit niet het geval is.

Taalgebruik

De sleutelwoorden "MOET/MOETEN" en "VEREIST" in dit document moeten worden opgevat als "MUST" in RFC 2119, "MOET NIET/MOETEN NIET" en "MAG NIET/MOGEN NIET" als "MUST NOT", "HOORT TE/HOREN TE" en "AANBEVOLEN" als "SHOULD", "HOORT NIET TE/HOREN NIET TE" als "SHOULD NOT", en "MAG/MOGEN" en "OPTIONEEL" als "MAY".

Doelstellingen

Deze gedragscode (de C4) is bedoeld als herbruikbaar model voor optimale samenwerking in open-sourcesoftwareprojecten. De C4 heeft de volgende specifieke doelstellingen:

  • De schaal en diversiteit van de community rond een project maximaliseren door de frictie voor nieuwe bijdragers te verminderen en een model voor deelname op grote schaal met sterke positieve feedback te creëren.
  • De afhankelijkheid van sleutelfiguren verminderen door verschillende vaardigheden te scheiden, zodat er een grotere groep geschikte kandidaten is voor elke vereiste taak.
  • Zorgen dat het project sneller en beter kan worden ontwikkeld, door grotere diversiteit bij het nemen van beslissingen.
  • De natuurlijke levenscyclus van projectversies ondersteunen, van experimenteel tot stabiel, door veilig experimenteren, snel mislukken en het isoleren van stabiele code mogelijk te maken.
  • De interne complexiteit van projectrepositories beperken, om het bijdragers gemakkelijker te maken om mee te werken en de kans op fouten te minimaliseren.
  • Collectief eigendom van het project afdwingen, waardoor bijdragers grotere economische prikkels hebben en het risico van overname door vijandige partijen wordt verminderd.
Ontwerp
Vooraf
  • Het project MOET het gedistribueerde versiebeheersysteem git gebruiken.
  • Het project MOET worden gehost op github.com of een vergelijkbaar platform, hierna genoemd "het Platform".
  • Het project MOET de issuetracker van het Platform gebruiken.
  • Het project HOORT duidelijk gedocumenteerde richtlijnen voor de stijl van de code te hebben.
  • Een "Bijdrager" is iemand die een patch aanbiedt, dat wil zeggen een verzameling commits die een duidelijk omschreven probleem oplossen.
  • Een "Maintainer" is een beheerder die patches merget in het project. Maintainers zijn geen ontwikkelaars. Hun werk is gericht op het regelen van processen.
  • Bijdragers MOGEN NIET het recht hebben commits toe te voegen aan de repository, tenzij ze ook Maintainers zijn.
  • Maintainers MOETEN het recht hebben commits toe te voegen aan de repository.
  • Iedereen MOET hetzelfde recht hebben om een Bijdrager te worden onder de voorwaarden van dit contract, zonder onderscheid of discriminatie.
Licentie en eigendom
  • Het project MOET een licentie op basis van Gelijk Delen gebruiken, bijvoorbeeld versie 3 van de GPL of een variant daarvan (LGPL, AGPL), of versie 2 van de MPL.
  • Alle bijdragen aan de broncode van het project ("patches") MOETEN dezelfde licentie gebruiken als het project.
  • Alle patches zijn eigendom van de auteur. Er MOET geen proces zijn voor het toekennen van auteursrecht.
  • De auteursrechten op het project MOETEN collectief eigendom van alle Bijdragers zijn.
  • Iedere bijdrager MOET er zelf verantwoordelijk voor zijn om zich te identificeren in de lijst met Bijdragers van het project.
Vereisten aan patches
  • Maintainers en Bijdragers MOETEN een account bij het Platform hebben en HOREN hun echte naam of een bekend pseudoniem te gebruiken.
  • Een patch HOORT een zo beperkt mogelijke en correcte oplossing van precies één omschreven en erkend probleem te zijn.
  • Een patch MOET voldoen aan de richtlijnen voor de stijl van de code van het project, als die zijn gedefinieerd.
  • Een patch MOET voldoen aan de richtlijnen die hieronder worden uiteengezet onder "Wijziging van openbare contracten".
  • Een patch MAG NIET substantiële code uit andere projecten bevatten, tenzij de Bijdrager zelf de oorspronkelijke auteur van die code is.
  • Een patch MOET ten minste op het belangrijkste systeem zonder problemen kunnen worden gecompileerd en slagen voor de zelftests van het project.
  • Het commitbericht voor een patch HOORT te bestaan uit één korte regel (minder dan 50 tekens) waarin de wijziging wordt samengevat, eventueel gevolgd door een lege regel en een uitvoerige omschrijving.
  • Een "correcte patch" is een patch die aan de bovenstaande vereisten voldoet.
Ontwikkelingsproces
  • Wijzigingen in het project MOETEN het patroon volgen van eerst nauwkeurig problemen vaststellen en vervolgens zo beperkt mogelijke correcte oplossingen voor deze problemen toepassen.
  • Een gebruiker die om wijzigingen wil vragen HOORT een issue aan te maken in de issuetracker van het project op het Platform.
  • De gebruiker of Bijdrager HOORT in het issue het probleem te beschrijven dat hij/zij ondervindt of waarneemt.
  • De gebruiker of Bijdrager HOORT te streven naar consensus over de juistheid van zijn/haar waarneming en over hoeveel het waard is om het probleem op te lossen.
  • Gebruikers MOGEN NIET issues aanmaken voor functieaanvragen, ideeën, suggesties of oplossingen van problemen die niet expliciet zijn gedocumenteerd en bewezen kunnen worden.
  • De versiegeschiedenis van het project MOET dus bestaan uit een lijst met gelogde en opgeloste issues van betekenis.
  • Een Bijdrager die aan een issue wil werken MOET een fork van de projectrepository maken en vervolgens aan zijn/haar eigen gevorkte repository werken.
  • Een Bijdrager die een patch wil indienen MOET een pull request naar het project op het Platform aanmaken.
  • Een bijdrager MAG NIET wijzigingen direct in het project doorvoeren.
  • Als pull requests op het Platform worden geïmplementeerd als issues, MAG een Bijdrager een pull request direct verzenden zonder een afzonderlijk issue aan te maken.
  • Mensen die een patch willen bespreken MOGEN reageren op het pull request op het Platform, op de commit of elders.
  • Een Maintainer MOET de interface van het Platform gebruiken om een patch te accepteren of te weigeren.
  • Maintainers HOREN NIET hun eigen patches te mergen, behalve in bijzondere omstandigheden, bijvoorbeeld als andere Maintainers langere tijd (meer dan één of twee dagen) niet reageren.
  • Maintainers MOGEN NIET waardeoordelen geven over correcte patches.
  • Maintainers MOETEN correcte patches van andere Bijdragers prompt mergen.
  • Bijdragers MOGEN een issue markeren als "Ready" (gereed) nadat ze een pull request voor het issue hebben gemaakt.
  • Gebruikers die een issue hebben aangemaakt HOREN het issue te sluiten nadat ze hebben gecontroleerd dat de patch geslaagd is.
  • Maintainers HOREN te vragen om verbeteringen in onjuiste patches en HOREN onjuiste patches te weigeren als de Bijdrager niet constructief reageert.
  • Een Bijdrager die een waardeoordeel heeft over een correcte patch HOORT die te uiten via een eigen patch.
  • Maintainers MOGEN wel wijzigingen in documentatie buiten de broncode direct in het project doorvoeren.
Stabiele releases creëren
  • Het project MOET een branch hebben (de "master") waarin altijd de nieuwste versie staat waaraan wordt gewerkt. Deze HOORT altijd gecompileerd te kunnen worden.
  • Het project MAG NIET topic branches (tijdelijke branches voor een specifiek doel) gebruiken, om geen enkele reden. In persoonlijke forks MOGEN wel topic branches worden gebruikt.
  • Om een stabiele versie te maken MOET iemand een fork van de repository maken door deze te kopiëren en dus maintainer van deze repository te worden.
  • Voor stabilisatie MAG een project eenzijdig en zonder toestemming van de maintainers van het project worden gevorkt.
  • Een stabilisatieproject HOORT te worden beheerd volgens hetzelfde proces als het hoofdproject.
  • Een patch van een stabilisatieproject dat is gemarkeerd als "stable" MOET vergezeld gaan van een herhaalbare testcase.
Wijziging van Openbare Contracten
  • Alle Openbare Contracten (API's of protocollen) MOETEN worden gedocumenteerd.
  • Alle Openbare Contracten HOREN ruimte te bieden voor uitbreiding en experimenten.
  • Een patch waardoor een stabiel Openbaar Contract wordt gewijzigd HOORT de werking van bestaande applicaties NIET aan te tasten, tenzij er consensus heerst over de waarde hiervan.
  • Een patch waarmee nieuwe functies worden toegevoegd aan een Openbaar Contract HOORT daarvoor nieuwe namen te gebruiken.
  • Oude namen HOREN systematisch verouderd verklaard te worden door nieuwe namen te markeren als "experimental" totdat ze stabiel zijn, en vervolgens de oude namen te markeren als "deprecated".
  • Wanneer voldoende tijd is verlopen, HOREN verouderde namen te worden gemarkeerd als "legacy" en uiteindelijk te worden verwijderd.
  • Oude namen MOGEN NIET worden hergebruikt voor nieuwe functies.
  • Als oude namen zijn verwijderd, MOETEN implementaties ervan een uitzondering (waarschuwing) veroorzaken als ze worden gebruikt door applicaties.
Projectbeheer
  • De oprichters van het project MOETEN optreden als Beheerders om te bepalen wie Maintainers van het project zijn.
  • De Beheerders MOETEN zorgen voor hun eigen opvolging op de lange termijn door de meest effectieve Maintainers te bevorderen.
  • Een nieuwe Bijdrager die een correcte patch toevoegt MOET worden uitgenodigd om Maintainer te worden.
  • Beheerders MOGEN Maintainers verwijderen die langere tijd niet actief zijn of die meermaals dit proces niet just toepassen.
  • Beheerders HOREN "kwaadwilligen" die anderen binnen het project kwetsen of stress bezorgen te blokkeren of te weren. Dit HOORT te worden gedaan na openbare discussie, waarbij alle partijen de kans krijgen om te spreken. Een kwaadwillige is iemand die herhaaldelijk de regels en cultuur van het project negeert, die ruzie zoekt, vijandig is of mensen beledigt, en die zijn/haar eigen gedrag niet corrigeert wanneer anderen daarom vragen.

Translated by Edwin den Boer, September 2018. Translation funded by the Monero community and published under the GNU General Public License version 3.