commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <grobme...@gmail.com>
Subject Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Date Wed, 10 Aug 2011 13:47:48 GMT
> 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 hate committocracy from the bottom of my heart. I would leave the
ASF immediately if the model would change to that.
bureaucratically open source - no thanks.

So, why do you want to measure my coding efficiency? Not even my Boss
(if I would have one) is allowed to do that! Commit points measure my
coding skills probably, not my human skills.

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

There are many options.

If it is 1:10, the 1 should think about his arguments.
If it is 5:5, people can make optional modules; or try out which works better
At least it is possible to make branches.
And everything else which comes to your mind.

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

If you have 1 with 200 commit points, and 3 with 30 each, then the one
is the leader/ruler. If it is to the leaders liking, then a consens
can be found. If not, then the leader makes a decision. This is no
consens for people on a same level. But this "same level" is what I
like on the ASF. I am on the same level as everybody else in this
project even when others have done so much more.

The answer is, fellows trust me. If I vote somebody in, because of his
merits, then the merit is not code, it is trust. You cannot measure
trust and respect in codelines or commit messages.

Why commitocracy? Just because I could block a decision of my fellow?
If people are afraid that I could block decisions, then they should
not vote me into their project.

There is one difference between Commitocracy and Meritocracy (as the
ASF understands it). The ASF model is around community success, the
Commitocracy model is around software success.

> Governance models are not cast in stone. The apache model will need to
> improve over time or eventually become obsolete.

As everything else in this world. At the moment I can see a huge
number of projects coming to the ASF; a lots of new people coming
through the incubator. I cannot say how many leave or unsatisfied. We
would need to do an empiristic research to know that. But at the
moment my feeling is, it works very well.

I have read the blog post in question several times; I simply cannot
like it, i have tried to understand everything. Committocracy is not
the answer, at least not for me.

I would like to add that I have full respect to your (Cekis) ideas and
if something on my post is offending then it is because I am not very
good with english. I simply don't like the model, thats all :-)

Cheers,
Christian

>
> </rambling>
>
>> Hen
>
> --
> Ceki
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>



-- 
http://www.grobmeier.de

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


Mime
View raw message