On 10/08/2011 3:47 PM, Christian Grobmeier wrote:
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.
Commit points as described in my blog measure the number of days in
which a committer made commits. The measure is independent of the value
of the commits or the skills of the committer.
So for a git repository, the commit points accumulated by Alice can be
obtained with the following command:
git log --format='%ad %an' --date=short|uniq|grep Alice|wc -l
That's all there is to it.
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.
Votes based on commit points are necessary only when consensus cannot be
reached. The default actions is to discuss a given proposal and try to
reach consensus. Only after repeated failures is a decision made by a
vote weighted by commit points.
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.
You can trust someone without systematic agreement. There are many
people which I like, respect and trust without being always in agreement
with them. Presumably, the same goes for most people.
Committocracy addresses the situation where consensus cannot be reached.
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.
As the number of committers grow, it becomes harder and harder to reach
consensus on certain divisive issues.
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.
Committocracy is essentially about community building. I don't think it
makes sense to talk about a community governance model such as
committocracy without the community of committers being at the center.
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.
Indeed, evolution applies to most ecosystems.
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.
Sure. No problem.
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 :-)
No worries.
Cheers,
Christian
--
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
