> 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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://www.grobmeier.de --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
