...

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 (not just commons committers) has the right ask for karma (commit access) and have it granted. The right place to ask is on the commons-dev mailing list.

Components cannot be released from the sandbox. This means no binaries posted anywere on the apache site as "0.x" releases, as this implies that Apache supports the released code. Users of sandbox code are expected to extract the latest source from the source code repository and build the code themselves.

Commit access to the sandbox is unfortunately not available to people who are not existing Jakarta committers, no matter how good their idea. Such projects are generally encouraged to start somewhere like sourceforge.net. Once a solid community has been established and existing projects are using the component, it may be possible to integrate the project direct into commons if the project developers feel that is appropriate, and the commons community feels the component is a good fit with commons goals.

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.

...

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

For components that use Maven as their build tool (and that is most of them now), you should add your name to the developers list in the project.xml file rather than the STATUS file if you intend to work on a component.

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 <tt>\[VOTE\]\[RESULT\]</tt> which counts the binding VOTEs and tells people the result. 

...

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 definitely required:

• Compliance with Apache Software Federation policies. This means a full license at the top of every file. It means auditing the dependencies. It means ensuring the copyright date is correct on the licenses.
  

...

• Evidence of compliance with the charter. This means having the documents required in the charter including a PROPOSAL. (Please look through the charter.) Please list all committers. Something like 'all jakarta-foo committers' isn't acceptable - a list is needed.
  
• A good PROPOSAL. A good PROPOSAL is clearly written and tightly scoped (ie. specific rather than general). Commons components are small, resuable components. The commons does not do frameworks and anything frameworkesque is likely to be viewed with scepticism. A PROPOSAL that duplicates an existing component will probably be viewed with suspicion. This is not because duplication is disallowed (overlapping components are specifically allowed by the charter) but because it indicates that the PROPOSAL fails to indicate the essential difference between the proposed component and the existing one. For example, a PROSPOSAL for a small, fast, compact xml-object mapper with minimal dependencies would be more likely to succeed than a PROPOSAL for 'a better version of commons-digester'.
  
• The health of the development community. Fellow committers need to be persuaded that users will be supported and the code pushed forward by the listed committers. This is a major issue since there's only a limited amount of energy amongst the commons committers and no one wants to have to support a component whose committers have gone AWALAWOL.
  
• The people proposing the component. It's a sad fact of life but a PROPOSAL that comes from well known and respected Apache committers is more likely to be viewed positively than a PROPOSAL by people not well known to the Commons Team. Please don't get offended - you'll just need to work that little bit harder.
  

...