...

Apache Commons Etiquette

This page describes and attempts to explain some of the peculiarities of Jakarta Apache Commons. This is etiquette defined by the community rather than the formal rules (for those see http//jakartacommons.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 ettiquetteetiquette, 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 commons components share just two lists. Questions about components are best asked on commons-useruser@commons. Development is organized on commons-devdev@commons. Before posting questions to the \[http://jakartacommons.apache.org/site/mail2mail-lists.html#Commons list\], users are requested to search the archives to see if the question has been answered before.

...

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

Any ASF committer (not just Jakarta Apache 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.

...

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 mailing list and so you might need to contact them directly.

...

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 Commons PMC.

...

The Commons Proper

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

...

A VOTE is an official decision thread. Anyone can express a preference (by indicating +1, +0, -0 or -1 in the traditional manner) but only some votes are binding. All are encouraged to VOTE but traditionally (to ease the work required to tally the vote) (non-binding) is added by those who know their votes are non-binding. Only votes from Jakarta Commons PMC members are binding.

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 {{\[RESULT\]\[VOTE\]}} which counts the binding VOTEs and tells people the result. The tally should separate binding from non-binding VOTES.  It is also good to place a time limit on \[VOTE\] threads.  Finally, VOTE threads often digress into interesting discussions not directly related to the VOTE iteslf.  In these cases, it is better to start new threads with appropriate subject headers for the side discussions.  This makes it easier to navigate the list archives and also keeps the VOTE thread on track (or leads to it being stopped, where appropriate).

...

• 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 jakartacommons-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 AWOL.
  
• 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.
  

...