CodaLab Community Governance
Last update: December 30, 2013
CodaLab is an open-source, community-run project. A meritocracy model is used to govern the project’s needs, objectives and future goals.
The purpose of CodaLab is to provide an open-source platform to support and accelerate data and computationally-intensive research in a collaborative cloud-enabled environment.
Role: The core team is responsible for strategic planning, maintaining account information for Codalab at https://github.com/codalab/codalab and approving changes to the governance model. It also makes decisions when community consensus cannot be reached.
How to join: The core team is open to anyone who has invested a significant amount of time either as a Content Contributor (through uploading algorithms and datasets) or as a Framework Contributor of many patches. New members are accepted via majority vote by the existing members. Currently, the core team consists of developers, testers, and at least one representative from each of the current main university and industry partners.
Role: A Framework Contributor is anyone who submits a patch to the project that adheres to the mission statement. At first, the patches should be small, but can grow once Committers express confidence in the quality of the Framework Contributor’s patches. For non-trivial patches (over 50 lines of code): Before a Framework Contributor’s first patch is put into the repository they must sign a Contributor License Agreement (CLA). To request a CLA, send an email with your name and the project name (CodaLab) to email@example.com.
How to join: Submit a patch as a pull request to https://github.com/codalab/codalab. Patches must adhere to the conventions found at http://www.python.org/dev/peps/pep-0008/. All patches must be accompanied by unit tests before being accepted.
Role: Committers decide on whether patches from Framework Contributors are entered into the main code repository. Committers use lazy consensus (see below) to decide on whether to commit a patch from a Framework Contributor. If the discussion does not move towards a consensus a decision will be made by a majority of (voting) core team members.
How to join: You should be a Contributor (Framework or Content) and be nominated to the core team as a committer. Nominations should be sent to firstname.lastname@example.org. You may nominate yourself.
Role: The main value of CodaLab comes from having the user-contributed content (the algorithms and datasets) on http://www.codalab.org, which can be edited in a Wikipedia style and used by anyone. The Content Contributors’ goal is to make the content organized and maximally useful.
How to join: Contribute a handful of high-quality general modules or add documents/tutorials to http://www.codalab.org.
Public discussions on any CodaLab topic should be held on the email@example.com discussion group.
Non-public discussions on issues of governance, overall strategy and implementation issues are held at firstname.lastname@example.org. This discussion group is available to Committers only (see above). Note that this is not intended to be used frequently; by default all discussions should be open to everyone.
Decisions are made default by lazy consensus: Someone (e.g., a committer) makes a proposal. If there are no objections within 72 hours, he or she can assume the community is in consensus and can move ahead with its implementation. If a consensus cannot be reached, then the core team votes.
Decision-making is made in a transparent, open fashion. No decisions about the project’s direction, bug fixes or features may be done without community involvement and participation.
This document is based on work by the Outercurve Foundation: http://www.outercurve.org/Resources/Wiki/Page/Committee-Governance