commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-commons Wiki] Update of "JakartaCommonsEtiquette" by PhilSteitz
Date Sat, 04 Mar 2006 17:50:22 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" for change notification.

The following page has been changed by PhilSteitz:
http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette

The comment on the change is:
Changed "Jakarta" to "Apache" re commit,  combined and updated voting info

------------------------------------------------------------------------------
  
  = 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. 
+ 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
Apache 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.
+ 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 Apache 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 :)
- 
  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 =
+ = VOTEs and POLLS =
  
- 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. 
+ 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.
+ 
+ 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. 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!).
  
  ----
  
@@ -96, +98 @@

  
  * Please give the proposal enough time to give everything the chance to VOTE. I leave promotion
VOTEs several days - maybe up to a week. When VOTEs have stopped coming in then please the
proposer should post a {{{[VOTE][RESULT]}}} giving counts. Only the VOTEs of commons committers
are binding so please make sure that these are tallied separately. The reason why a result
email is good is that VOTE thread tend to peter out and so without a final email, it's hard
to look back through the archives and find out what's happened. Another reason is that it's
a good way to let everyone know what the result was. If there are any disagreements about
the result, they can be resolved then. 
  
- = Ettiquette - VOTEs (binding and non-binding) 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.
- 
- 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!).
- 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message