On Wed, Aug 10, 2011 at 9:06 AM, Ceki Gülcü <c...@qos.ch> wrote: > On 10/08/2011 8:02 AM, Henri Yandell wrote: >> >> On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu<c...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
