Apache Labs Bylaws

The Apache Labs project was established by the board at the November 2006 meeting. This page is based on the bylaws appendix submitted to the board along with the resolution to establish the project.

Summary

The Apache Software Foundation is well known for its motto community is more important than code and has designed its incubation facilities accordingly.

While healthy and diverse open development communities provide a very efficient solution for self-sustaining, long-lasting and well-adapting software development practices, the creation and bootstrap of such community is normally a long and emotionally expensive process.

Moreover, in order to provide a seed to grow and ground discussions on technical levels, the ASF incubation rules require the podlings to join the incubation process with an established and working codebase.

While this is a tremendous benefit for the incubator (because setting the bar high avoids it to have to do the filtering and dissipating the negative energy that would develop in such a process), it also implies that the ability for the ASF to innovate is left at the top level projects that graduated out of incubation.

Several of these projects provide places for their committers to work on innovative ideas (these are normally called sandboxes or whiteboards). Unfortunately, such efforts are constrained by the project bylaws, which can limit the degree of innovation that such efforts can exhibit.

Apache Labs are the place where ASF committers can work on innovative, blue-sky and off-the-wall ideas, without having to worry about fitting in an existing project bylaw or building a community around it, but unlike other external venues that can offer similar hosting services, as a place where fellow committers can offer suggestions and help.

Guidelines

Infrastructure

The Apache Labs project infrastructure is composed of the following parts.

• a vm (labs-vm.apache.org) for experimenting
• a site (http://labs.apache.org/)
• three mailing lists:
  • labs@labs.apache.org
  • commits@labs.apache.org (this receives the svn commits diffs)
  • private@labs.apache.org
• a lab registry (a collection of machine-readable descriptors)

Access

Every ASF committer has both read and write access to the entire Labs SVN repository.

The Labs PMC will not ask for commit access for people that are not already ASF committers.

Mailing Lists

See here for details of the three Labs mailing lists.

The Labs PMC will not ask for lab-specific mail lists.

New Labs

Every ASF committer can ask for one or more labs. The lab creation requires PMC lazy concensus, if no PMC sends a mail with -1 to labs@labs.apache.org within the lazy consensus period (72hours), the lab request is accepted.

If approved, the ASF committer will create the lab on his/her own and register the lab's descriptor in the lab registry. The committer that asks for the lab becomes known as that lab's PI (principal investigator). The PI is the sole responsible for keeping their lab descriptor up-to-date. Failure to do so can result in lab completion.

Releases

Labs are prohibited from making releases.

PMC members

A Labs PMC member can resign at any time. The PMC can elect another ASF committer as Labs PMC member at any time. Only ASF committers can become members of the Labs PMC. The elected ASF committer reserves the right to reject the nomination without justification.

Principal Investigator (PI)

A Lab PI can resign and select another committer as PI just by communicating so to the PMC. It becomes effective if the new PI accepts.

Existing Sandbox Projects

The Apache Labs will welcome existing lab-like efforts (sandboxes, whiteboards) from existing ASF TLPs to become labs.

Bylaw Changes

Changes to the Apache Labs bylaws require a 2/3 vote from the PMC members.

Lab Lifecycle

A lab can have four states:

• Active
• Idle
• Promoted
• Completed

The Labs PMC can change the state of a lab with a majority vote. In any vote when a lab state is changed, and in such votes only, the lab's PI's vote will be counted along with the PMC members' to form majority.

Active

Activity is happening. When a lab is re-activated, the descriptor is changed accordingly and a the boilerplate disclaimer is removed from the README file.

Idle

Activity is paused but it will be resumed in the future. When a lab is idled, the descriptor is changed accordingly and a boilerplate disclaimer is placed in the README file. The lab PI can change the state of the lab from active to idle and back at any time, just by updating the descriptor.

Promoted

Lab started incubation. When a lab is promoted, the files are moved over to the incubation area.

Completed

Activity has been completed and unlikely to resume in the future. When a lab is completed, the lab is archived and removed from SVN.

Guidelines Rationale

Lazy consensus (72 hour) is used to make it easy to create a lab.

The reason why the lab PI is included in the state change vote is to act as arbiter in case the PMC is undecided. It also gives the feeling of participating in the decision-making process.

The reason why the Labs PMC has the power to vote a state change even if the lab PI is in disagreement is to allow the PMC to promote those labs that become too active even if the labs PI and participants would rather stay in the labs.

The reason why the Labs PMC has to perform a lazy vote on the establishment of a lab is to provide oversight with a minimal overhead. Such oversight is meant to avoid the abuse of labs as personal backups or dumping grounds, which would be off-topic in the Labs' mission, or use labs as a way to fork existing efforts and route around incubation practices. It also allows the PMC to allow labs only if they have a functional machine-readable descriptor, which allows the automation of the information gathering about the labs.

The reason why the Labs PMC cannot create new mailing lists or institute new committers is to avoid labs to become a way for people to route around the incubator (and also to avoid add more work to infrastructure)

The reason why Labs are prohibited from making releases is to simplify operation and avoid the legal oversight associated with the release process and to avoid labs from becoming ways to route around the incubator.

The reason why Labs have a fixed number of mailing lists is to force people to watch over other's people's shoulders, to avoid mail-list creation load on infrastructure and to provide a comfort threshold that successful labs can easily trigger as an indicator that they might be ready for promotion into the incubator.

The reason why all committers have write-access to all labs is to avoid adding infrastructure costs and to simplify collaboration. The use of version control, the selected nature of committership and the existence of a single communication channel guarantee minimal risks and collision costs in doing so.

The reason why labs must have a machine-readable descriptor is to allow automation of lab metadata gathering and web site publishing in order to scale to hundreds of labs and provide more effective oversight.