Jakarta Commons Etiquette

This page describes and attempts to explain some of the peculiarities of Jakarta Commons. This is etiquette defined by the community rather than the formal rules (for those see http//jakarta.apache.org/commons/charter.html). This page was created (after several requests for information) to satisfy developers and committers rather than users. (But if anyone wants to add user ettiquette, that'd be cool :)

The wiki seemed like a good place where this could be informally developed by the community. It might become a web page later (and then again, it might not).

The information contained in this page is unoffical advice rather than rules that have been officially adopted by the Commons team. It was founded by observations of the goings on in the commons from the subproject's creation till the present.


The Sandbox

The sandbox is a space provided by Jakarta for the development of experimental code by existing committers. It is divided into components.

Any Jakarta committer has the right ask for karma and have it granted. The right place to ask is on the commons-dev mailing list.

Sandbox Etiquette

Committers have karma for the whole sandbox. This means that a committer could alter any component. But we're all grown ups (right?) and so we'll play nicely together (right?). The right thing to do is to ask on the list or talk to the owners of the component (see the STATUS file) before diving in. The owners may not be still subscribed to the commons-dev list and so you might need to contact them directly.

A little patience and discussion in this will avoid flames later :)

Sandbox Oversight

Oversight for the sandbox is provided by the Commons team. Oversight means responsibility for ensuring that everything in the sandbox complies with Apache Software Foundation policies. Though (it is to be hoped that) committers should be able to be trusted, in the last resort the Commons team reserves the right to remove offending material from CVS.

If questionable material is found, the right way to proceed is to first raise the matter on the commons-dev mailing list. The community will form a judgement about the material and the committers will be able to respond. It's a good idea to inform the committers directly (in case they are not on the list). It's also a good idea to copy the Jakarta PMC.


The Commons Proper

The Commons Proper consists of small, reusable components each developed independently.

Commons Committers

The commons proper is governed by the same membership rules as any other jakarta subproject. That means committers are elected. Unlike the sandbox, there are no automatic rights for existing Jakarta committers.

On the other hand, the barrier to entry for existing Apache committers has traditionally been pretty low. If you express an interest, show willing by creating a few patches and you're known to existing committers, there's usually no problem. VOTEs proposed by commons committers for existing jakarta committers listing their achievements have (in the past) been passed very quickly.

Commons Etiquette

Every commons committer has karma to every component. But a point of etiquette (enforced by the charter) is that each committer who commits to a component must add their name to the STATUS file for that component. It's also good form to post a message saying 'hi, i'd like to get involved with component foo' before you dive in. Traditionally, adding your name to the STATUS file is a committers first commit on a component.

There is one important point about the list on the STATUS file. It is used to work out whose VOTEs are binding. (Since there are a lot of commons committers, this is more useful than it might first seem.) If you're name isn't on the list, your vote won't count :)

VOTEs

The commons-dev mailing list is a busy place. Very much a bazaar rather than a Cathedral. This means that VOTE threads have a habit of petering out. It a good idea to post a ["VOTE"][RESULT]  which counts the binding VOTEs and tells people the result.


Promotion

Promotion is the process by which components move from the sandbox into the commons proper.

Promotion to the commons proper is not the only route out of the sandbox. The commons proper isn't always the best place for all components from the sandbox. There isn't any reason why a component couldn't move directly from the sandbox to become a project or a subproject. At least one component has moved from the sandbox to sourceforge and then finally back to the incubator.

Promotion is basically a beauty contest. If the component can win enough votes and few enough people vote against it, then the component is promoted. But there is one thing that is most definitly required:

There some points of etiqutte and a few criteria that (though they are not rules) often seem to influence the voting.

Ettiquette - Proposing A Promotion VOTE

JakartaCommonsEtiquette (last edited 2009-09-20 23:50:00 by localhost)