commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Commons Wiki] Update of "JakartaCommonsEtiquette" by DennisLundberg
Date Sun, 05 Aug 2007 20:12:40 GMT
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
user@commons. Development is organized on dev@commons. 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message