Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification.
The following page has been changed by DennisLundberg: http://wiki.apache.org/commons/JakartaCommonsEtiquette The comment on the change is: TLP changes ------------------------------------------------------------------------------ - = Jakarta Commons Etiquette = + = Apache 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 :) + This page describes and attempts to explain some of the peculiarities of Apache Commons. This is etiquette defined by the community rather than the formal rules (for those see http//commons.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 etiquette, 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). @@ -12, +12 @@ = Mailing Lists = - The commons components share just two lists. Questions about components are best asked on commons-user. Development is organized on commons-dev. Before posting questions to the [http://jakarta.apache.org/site/mail2.html#Commons list], users are requested to search the archives to see if the question has been answered before. + The commons components share just two lists. Questions about components are best asked on [EMAIL PROTECTED] Development is organized on [EMAIL PROTECTED] Before posting questions to the [http://commons.apache.org/mail-lists.html#Commons list], users are requested to search the archives to see if the question has been answered before. When sending mail, please add a prefix containing the name of the component. For example, if the mail concerns '''commons-foo''', the subject should be prefixed with '''[foo]'''. The volumes on the development list are high. This can be difficult to manage without using filters to sort the mail. Most email clients allow filtering on subject and this convention allow developers to pick out the components they are interested in more quicky. @@ -20, +20 @@ = The Sandbox = - The sandbox is a space provided by Jakarta for the development of experimental code by existing committers. It is divided into components. + The sandbox is a space provided for the development of experimental code by existing committers. It is divided into components. - Any ASF committer (not just Jakarta 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. + Any ASF committer (not just Apache Commons committers) has the right ask for karma (commit access) and have it granted. The right place to ask is on the 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. @@ -30, +30 @@ = 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. + 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 dev mailing list and so you might need to contact them directly. A little patience and discussion in this will avoid flames later :) @@ -38, +38 @@ 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 the source code repository. - 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. + If questionable material is found, the right way to proceed is to first raise the matter on the 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 Commons PMC. ---- @@ -60, +60 @@ = VOTEs and POLLS = - 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 PMC members are binding. + 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 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). + The 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). A POLL is an unofficial decision thread. These are useful for gauging the general feeling of the broader user community. Again, preferences should be expressed in the usual fashion. In this case, there is no need to indicate non-binding (since none are!). @@ -80, +80 @@ There some points of etiqutte and a few criteria that (though they are not rules) often seem to influence the voting. - * 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. + * 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 commons-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'. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
