commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Date Wed, 10 Aug 2011 13:59:42 GMT
On Wed, Aug 10, 2011 at 9:06 AM, Ceki Gülcü <ceki@qos.ch> wrote:
> 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.

"Creating a branch of commons-digester using SLF4J/jul/log4jv2 will
not convince anyone."

I am sorry, but deciding for other people what they are going to think
is no way to go either.

Experimenting by branching is leading by example. This is a good
option when a discussion on a mailing list stalls or is caught in a
loop. Some people can see it all in the abstract and in words but
trying code out can help everyone see an issue clearly.

Cheers,
Gary

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



-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

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


Mime
View raw message