This page is meant to outline a proposed new distributed development process for Boost C++ Libraries.

== Rationale ==

* '''We want to lower the barrier to entry for contributors to the Boost C++ Library.''' In the current centralized development process, contributors are discouraged from contributing because:
  * Patches in Trac don't get applied quite fast enough because a maintainer still has to manually do it.
  * Getting commit access to the central repository is a manual process.
  * Before anybody can typically help in the maintenance of a library, that person has to do quite a lot of work without much certainty of success, and in the end mostly is a judgment call by an original maintainer.
* '''We want to make including libraries into a Boost Distribution a trivial process.''' In the current centralized process this means moving the code into a central repository then having maintainers manually merge the changes from the main development branch (trunk) into the release branch -- this is a problem because the risk of failure is high.
* '''We want to increase community participation in different aspects of the project like testing, promotion, documentation, BoostCon, and  standardization.''' At the moment there's a lot of work to be done for Boost libraries but a lot of it has not been properly identified and publicized. This is coupled with the high barrier to entry for contributors and you have only a small community of developers trying to do all the work that other non-developers may very well be able to do. With regard to standardization, there are Boost C++ Libraries that would be great to have in the ISO standard -- the effort of championing these libraries currently fall on the shoulders of just the library maintainer, which can be done by others already in the committee or someone else willing to champion that effort.
* '''We want to enable the Boost project to scale up to have more than one distribution.''' As it is at the moment there is only one Boost C++ Library distribution which contains all the accepted libraries.

== Definitions ==

Before moving on to the specifics, we need to define a few terms we're using:

* A '''Contributor''' is a person who does at least one of the following:
  * Submit patches to library code, documentation, build systems, tests, and anything materially tangible that's considered part of a library project (logos, websites, blog entries, etc.).
  * Reports issues with the library which means she has used it in a given context and is considered a testing contribution.
  * Merges patches into the a library on his personal branch/fork of the library and runs tests locally on his system.
  * Runs regression tests for a particular Boost distribution (see distribution below).
  * Shepherds contributions in from other sources into the main library.
  * Donates money or resources to making sure that the library effort continues.
* A '''Distribution''' is a collection of reviewed and accepted libraries. There can be many different types of distributions some of which are listed below:
  * Theme-based distributions (Metaprogramming, Algorithms, Containers, etc.)
  * Layer-based distributions (Core, Utilities, Extensions)
  * Maturity-based distributions (Stable, Unstable, etc.)
* A '''Release Manager''' is a person who:
  * Pulls together published versions of the libraries in the distribution that she manages.
  * Coordinates the efforts of contributors for libraries that are part of the distribution to get a given release tested, packaged, and distributed for general availability.
  * Signs off (literally, with his GPG Key, see "Web of Trust" below) on all changes merged into a release.
* The '''Web of Trust''' system relies on:
  * Contributors having signed GPG keys and publicly available public keys who sign all their contributions as well as those they shepherd into his own branch/fork.
  * Library Maintainers who have their signed GPG keys and publicly available public keys who pull in contributions from contributors and signs off on all their changes as well.
  * Release Managers who have their signed GPG keys and publicly available public keys who sign all the changes they pull in and all the tags they define for releases.
  * The web of trust signifies:
    * If a Contributor's GPG key is signed by a library maintainer, then that contributor is eligible to become a library maintainer.
    * A Release Manager may choose to pull changes that are not library maintainer-signed in case a library maintainer is not active or not available.
    * If a Release Manager chooses to sign a Contributor's key, that makes the Contributor eligible for maintaining a library which may potentially have the original library maintainer unavailable; in this situation, a Contributor is promoted to Library Maintainer from the trust system.
    * If two or more Release Managers sign either a Contributor's or Library Maintainer's key, that makes that person eligible to become a release manager of the distribution or distributions where the signing release managers are release managers of.
    * It is preferred -- but not required -- that people sign keys only if they have met in person or that they can say with reasonable certainty that this person they're signing the keys of is actually someone they trust. It's suggested that BoostCon or local Boost User Group events be the venue where key exchanges and key signings happen.
  * A Trusted Contributor, Trusted Library Maintainer, or Trusted Release Manager is a person who has at least two peers in the same or higher level (Contributor < Library Maintainer < Release Manager) signing with high trust levels.
* An '''Official Boost Release''' is an official release that is packaged and signed by a Trusted Release Manager.
* A '''Review Manager''' is a person who:
  * Drives the Review Process (see Review Process below)
  * Is responsible in collating and maintaining a record of reviews regarding the inclusion of a Candidate Library (see Candidate Library below)
  * Is poised to be a Library Maintainer of the library under review once it is accepted
  * Is at least a Library Maintainer or Release Manager, or used to be a Review Manager Assistant promoted to be eligible to become a Review Manager
* A '''Review Manager Assistant''' is:
  * Assist the driving of the Review Process (see Review Process below)
  * Is poised to be (or is already) a Contributor to the library under review once it is accepted
* The '''Boost Community''' is the group of people who are any one of the following:
  * A Contributor
  * A Library Maintainer
  * A Release Manager
  * A Review Manager
  * A Review Manager Assistant
  * A Registered Boost User -- a listed member of the Boost Users, Boost Developers, or BoostCon mailing lists who is not any one of those already mentioned above
* A '''Candidate Library''' is a library being considered or developed for inclusion in Boost. The criteria for Candidate Libraries are:
  * The project repository is publicly available.
  * The library follows the Boost Code Guidelines.
  * The library and all artifacts are available under the Boost Software License.
  * The library has all copyrights explicitly defined.
  * The library has been explicitly posted to be considered a Candidate Boost Library to the following venues:
    * The Boost Users Mailing List
    * The Boost Developers Mailing List

== Processes ==

This section describes the processes by which the development of Boost Libraries proceed in a distributed manner.

=== Review Process ===

There are two types of reviews:

* '''Acceptance Review''' -- the process through which a Candidate Library is reviewed to be accepted.
* '''Maintenance Review''' -- the process through which all accepted libraries undergo on a regular basis to determine whether it should be deprecated, updated, replaced, or dropped from Boost.

==== Acceptance Review ====

The Acceptance Review is driven by at least one Review Manager. The Acceptance Review process goes as follows:

1. A Candidate Library is identified signalling the beginning of the process.
1. A Review Committee for the Candidate Library is convened for the library which consists of:
  * At least one Review Manager.
  * At least one Review Manager Assistant.
  * At least one Trusted Release Manager.
1. During the course of the review period, members of the Boost Community answer a set of questions regarding the suitability of a library to be made part of Boost relating to:
  * The design and implementation of the library.
  * The documentation of the library.this is done by Review Managers, Review Manager Assistants, and Trusted Release Managers.
  * The functionality provided by the library.
  * Suitability in real-world application conditions (implies testing on actual platforms, not necessarily in production).
1. A conformance test script is run regularly on the library to see whether it satisfies the technical requirements for inclusion in a larger Boost distribution.
1. Once a month the members of the Boost Community are surveyed to list down which Candidate Libraries are fit for acceptance into Boost.
1. The Candidate Libraries at the top of the list are then checked for whether the issues raised by the community have been addressed appropriately by the Review Committee.
1. A Candidate Library is accepted when:
  * The Review Committee agrees that the issues raised by the community have been addressed properly.
  * The conformance test script raises no errors.

Once a library is accepted, the following things happen:

* The Review Managers involved in the process are considered Library Maintainers of the library along with the original Library Maintainers.
* The Review Manager Assistants involved in the process are considered Contributors to the library.
* The Review Manager Assistant is then evaluated by the peers in the Review Committee and may be promoted to becoming eligible to be a Review Manager
* The Release Manager in the Review Committee then pulls the latest tagged release version of the Candidate Library into the distribution she is responsible for

The Acceptance Review process runs until the Candidate Library is accepted. Candidate Libraries may be removed from active review if:

* The project is deemed to be no longer active.
* There is a request to remove the Candidate Library from active review from the original submitter.

Note:

* There is no time limit to the length of an Acceptance Review.
* The notes of an Acceptance Review are maintained in a Wiki to be regularly maintained by any member of the Review Committee.
* Issues raised on Candidate Libraries should be filed as issues in the appropriate issue tracking system associated with the Candidate Library.