On Wed, Aug 10, 2011 at 6:06 AM, Ceki Gülcü <c...@qos.ch> wrote: > On 10/08/2011 8:02 AM, Henri Yandell wrote: > > <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 was going to say: "That would put Sebb in charge of the ASF!!!", but then I noticed that after the import of Jena Andy Seaborne appears to be the top count committer (I know, that doesn't measure size of commit). [http://svnsearch.org/svnsearch/repos/ASF/search] I think the problem with this is that it's an extremely arbitrary way of dealing with failure to find consensus. It's also not very meritocratic - it's based on what people have done and not what people are willing to do. The 'prove it in a branch' is more merit-based and less likely to result in status quo decisions. > 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. Agreed - the work to move from one logger to another is presumably very easy for us. Much more of a pain for users, so I'd expect there to be resistance to change there. The interesting one will be whether a new component (or one adding logging) would hit resistance from using a different system. Some of the discussion was also not about what we should use, but whether commons-logging was done, dead etc [puts on the Attic hat]. Currently c-logging has 2 bugs fixed in trunk but no release imminent. They don't seem like trivial bugs, so I contend we should either be thinking of a release or thinking of making the component dormant. > 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. Yup - . It's a good conversation to have had - great to hear of log4j 2.0 work and to have you still active in the conversation. Looking at Commons, there are 17 components using c-logging (+5 in the sandbox) and 2 also using slf4j. DBCP 2.0 represents the most likely time on the horizon that a component would consider changing. > 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). Definitely the right way to focus on it - what are the mechanisms for handling breakdown of consensus. Too often it's the loudest-wins, or the one willing to hang in the longest, or the one willing to be the most obstinate. I think committocracy is too arbitrary to be agile - it casts things in stone that the general Apache approach leaves to the social structure. In practice the respect built from historical work is more often than not the 'winning vote', we all tend to defer to those who were here before us. That gets a bit warped as people move from project to project. jim@ is a Commons committer. He made 4 commits to CLI back in 2009, but I'm still likely to listen to him above and beyond his committocracy count. I can see how that might be a good thing or a bad thing depending on situation. > Governance models are not cast in stone. The apache model will need to > improve over time or eventually become obsolete. Yup, though I think there are other areas where adaptation is more likely to be needed than this one. Whether or not we should have CLAs is one that jumps to mind. How to stop employers buying committocracy (regardless of whether we have it as an official notion or its current social notion). Patents. Decentralized development (github-like - not the source-control but the ultra-bazaar dev style). Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
