Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.de;
  h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type;
  b=z3r9N/EVHJ9JxokRF9h7DOMH21sRxo7GaVHRp5RDFp8v0apwqC0T7x+O7+Ih+2aUpWv84fV+TdvNnBlrXmn10pNKrUI2NGXDvjlFdH5VBNfyC6y5hik72kjTXeL0biYI98xo2bcka6TrPN3YqLxHOXXpRpLc3KT562D5bY4bCgg=;
Message-ID: <1313017138.78301.YahooMailClassic@web27806.mail.ukl.yahoo.com>
Date: Wed, 10 Aug 2011 23:58:58 +0100 (BST)
From: Mark Struberg <struberg@yahoo.de>
Subject: Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
To: Commons Developers List <dev@commons.apache.org>
In-Reply-To: 
 <CAPFNckj5efgEjqyhXjfwc_xZb3XFN5i3XSAZfFSa67Wh0Gd_dg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Commits != work

I'm currently in the progress of rewriting plexus-utils and other stuff from over at codehaus to be able to use an IP clean version of it for Maven again. This is needed since some folks are throwing dirt and claiming that they did most of the work, yada yada yada...

Of course they had the most commits over at the codehaus SVN. But they did not say that 70% of the code did originally come from Apache Avalon (only found that out after reading Stefan Bodewigs @author tags and digged deeper).

So having the most commits != having done the most work!


LieGrue,
strub


--- On Wed, 8/10/11, Christian Grobmeier <grobmeier@gmail.com> wrote:

> From: Christian Grobmeier <grobmeier@gmail.com>
> Subject: Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
> To: "Commons Developers List" <dev@commons.apache.org>
> Date: Wednesday, August 10, 2011, 1:47 PM
> > 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
> 
> 

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