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 RahulAkolkar
Date Sun, 05 Mar 2006 02:48:43 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 RahulAkolkar:
http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette

The comment on the change is:
Use true wiki bullets, put [RESULT] before [VOTE] in result emails.

------------------------------------------------------------------------------
  
  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).
+ 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).
  
  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!).
  
@@ -76, +76 @@

  
  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
definitely required:
  
- * Compliance with Apache Software Foundation 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.
+  * Compliance with Apache Software Foundation 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.
  
  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 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'.
+  * 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 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.
+  * 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.
  
  = Ettiquette - Proposing A Promotion VOTE =
  
- * Discuss and try to formulate a consensus first. Promotion votes can (and do) get messy
unless this happens. Create a discussion thread on the list and try to find out any reasons
people might have for voting against. You might need to alter your charter, add missing files
or resolve dependency issues. It's easy for everyone if all main issues are sorted before
you propose the proper VOTE. If revisions to the proposal are required, the VOTEing can get
very messy.
+  * Discuss and try to formulate a consensus first. Promotion votes can (and do) get messy
unless this happens. Create a discussion thread on the list and try to find out any reasons
people might have for voting against. You might need to alter your charter, add missing files
or resolve dependency issues. It's easy for everyone if all main issues are sorted before
you propose the proper VOTE. If revisions to the proposal are required, the VOTEing can get
very messy.
  
- * Post a promotion email whose subject and body make it clear that this is a formal promotion
VOTE. The subject should be prefixed by {{{[VOTE]}}} and should be something like {{{[VOTE]
Promote commons-foo}}}. The body should be clear and fairly formal. 
+  * Post a promotion email whose subject and body make it clear that this is a formal promotion
VOTE. The subject should be prefixed by {{{[VOTE]}}} and should be something like {{{[VOTE]
Promote commons-foo}}}. The body should be clear and fairly formal. 
  
- * Proposal - always include a copy of the PROPOSAL that's being VOTE'd on in the VOTE email.
This is important since it is clear to everyone what they are VOTEing on. It also prevents
being put in the embarasing position of the PROPOSAL being VOTE'd on being modifed in CVS
half way through a VOTE thread. 
+  * Proposal - always include a copy of the PROPOSAL that's being VOTE'd on in the VOTE email.
This is important since it is clear to everyone what they are VOTEing on. It also prevents
being put in the embarasing position of the PROPOSAL being VOTE'd on being modifed in CVS
half way through a VOTE thread. 
  
- * 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. 
+  * 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 {{{[RESULT][VOTE]}}} 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. 
  

---------------------------------------------------------------------
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