commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Date Wed, 10 Aug 2011 13:06:29 GMT
On 10/08/2011 8:02 AM, Henri Yandell wrote:
> On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu<ceki@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message