======================================================
oRFC: 1 The Collective Code Construction Contract (C4)
======================================================
The Collective Code Construction Contract (C4) is an evolution of the
github.com `Fork + Pull Model `_,
aimed at providing an optimal collaboration model for free software
projects. This is revision 1 of the C4 specification.
+-----------+-----------------------------------------------+
| Name | C4.1 |
+-----------+-----------------------------------------------+
| Editor | Jeremy Rossi |
+-----------+-----------------------------------------------+
| State | Accepted |
+-----------+-----------------------------------------------+
| Origin | http://rfc.zeromq.org/spec:22 |
+-----------+-----------------------------------------------+
--------
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[#f1]_.
------
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 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 merge 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 the GPLv2 or a variant thereof (LGPL, AGPL).
* 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 initiate changes, a user SHOULD log an issue on the project
Platform issue tracker.
* The user SHOULD write the issue by describing the problem they
face or observe.
* The user 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.
* 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 SHALL NOT accept their own patches.
* Maintainers SHALL NOT make value judgments on correct patches.
* Maintainers SHALL merge correct patches 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) SHOULD 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.
Further Reading
===============
* `Argyris' Models 1 and 2 `_ -
the goals of C4.1 are consistent with Argyris' Model 2.
* `Toyota Kata `_ - covering the
Improvement Kata (fixing problems one at a time) and the Coaching Kata
(helping others to learn the Improvement Kata).
----------
References
----------
.. [#f1] "Key words for use in RFCs to Indicate Requirement Levels" - http://tools.ietf.org/html/rfc2119
.. [#f2] "Definition of a Free and Open Standard" - http://www.digistan.org/open-standard:definition
.. [#f3] "Consensus Oriented Specification System" - http://www.digistan.org/spec:1/COSS
-------
License
-------
Original content licensed under the Creative Commons Attribution-Share Alike 3.0 License.
(c) Copyright (c) 2007-2011 iMatix Corporation and Contributors.