On 10/08/2011 8:02 AM, Henri Yandell wrote:
On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu<c...@qos.ch> wrote:
* On the ASF model
In a nutshell, while the ASF is a great organization in many ways, it
is not a meritocracy mainly because merit is not measured at all and
at the project level no responsiblity is accrued on merit beyond
committership. BTW, the BDFL model is not a meritocracy
either. Finding a good model for running organisations is no simple
matter. The Apache model may even be better than some but it bothers
me that the ASF misrepresents itself as a meritocracy.
Yup.
Damn... should probably say more.
It tries to be meritocratic for adding committers. It's damn hard to
track how much someone is contributing sometimes. I wrote a JIRA
Contributions report that I like a lot - with each release I look and
see who was involved in the release and whether anyone who is a
non-committer stands out as having done a chunk.
Beyond that it's mostly peer/respect driven. Getting to be a member is
based on respect of peers; leading to new groups having low members
while the culture overlaps with the new group.
Discussions are still meritocratic, in that they favour those prepared
to do the work, but that's only at the meme level and not in any of
the actual methods; meaning you have to be pretty obstinate to push
past that inactive committer -1. The loose meme is that inactive
should only be casting -0 and +0.
Getting your way (per se) in discussions is also peer/respect driven;
meaning you have to expend energy on convincing others rather than
coding. An annoying drag on your time to code. There are culture memes
that can lessen that, but they're not well communicated.
Rules for Revolutionaries is definitely the best, though I rarely seem
to see it actually documented for a project. We don't have a rule for
revolutionary change for example. I spent lots of time trying to
convince people that we should do a JDK 1.5 Lang; then realized I
should just start on a branch (or trunk; I forget which).
So here's our Commons Rules for Revolutionaries:
* Give heads up. Make a branch and JFDI. Then discuss.
** Subnote. If not a Commons committer; then discuss making a
sandbox branch, make a branch and JFDI.
*** Subsubnote. If not an Apache committer; make a github fork or
svn copy, JFDI and discuss.
Maybe that will help someone in the future :) I always wonder if that
would have helped in log4j.
End of ramble :)
It does worry me, the balance between innovation and stability (rules
for revs), and the interaction of lots of skilled people. On the
latter the meme is "Go to ApacheCon". Meet someone face to face and
much of the irritation that can build up fades away.
<rambling scope="large" unabashed-plugin="true" >
Thank you for posting this summary of the Apache way. Yes, it is damn
hard to track contributions, especially if one wishes to do it
accurately and fairly. However, it is possible and even easy to keep
*approximate* track of contributions, e.g. via "commit points" as
described in my committocracy post.
I quite like the consensual approach you describe. Treating others
with respect goes a long way in convincing your audience. Yes, meeting
people face to face create bonds which then help to ease
tensions. However, while the consensual approach works nicely under
many circumstances it does not always work.
Take for example the logging issue recently discussed on this
list. Some argue in favor of adopting SLF4J, some in favor of j.u.l,
some in favor of log4j v2 and yet others wish to keep using
commons-logging. I don't see a way to reach consensus on this topic
regardless of the time and effort put into it. Creating a branch of
commons-digester using SLF4J/jul/log4jv2 will not convince anyone.
In the current system, I would expect commons-logging to be retained
because it's the path of least action/no decision. I should mention
that not deciding can sometimes be the best decision yielding the best
results. In other words, being conservative is often OK.
The alternative system I propose, namely committocracy, is merit-based
and where decisions can be reached in an orderly and timely fashion.
It specifically caters for cases where consensus cannot be
reached. IMO committocracy is not in contradiction with consensus
building as long as its use is restricted to special circumstances
(where consensus building has failed repeatedly).
Governance models are not cast in stone. The apache model will need to
improve over time or eventually become obsolete.
</rambling>
Hen
--
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
