You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2011/08/10 08:02:49 UTC
[general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu <ce...@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.
Looking forward to meeting many of you at ApacheCon Vancouver :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [general] Apache + Meritocracy
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-10, Henri Yandell wrote:
> On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu <ce...@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.
+1 to all you've said (including the stuff I snipped).
> 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.
> Looking forward to meeting many of you at ApacheCon Vancouver :)
Or any of the smaller opportunities that pop up every now and then. For
those of us in Europe who won't make it to Vancouver the next one seems
to be Amsterdam in October:
http://wiki.apache.org/apachecon/AmsterdamHackathon2011
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Posted by Ceki Gülcü <ce...@qos.ch>.
On 10/08/2011 3:59 PM, Gary Gregory wrote:
>
> "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.
"Creating a branch of commons-digester using SLF4J/jul/log4jv2 will
not convince anyone" because it is a trivial exercise. The sentence
should *not* be generalized to all experiments and branches. It applies
only to replacing one logging API with another fairly similar logging
API.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Aug 10, 2011 at 9:06 AM, Ceki Gülcü <ce...@qos.ch> wrote:
> On 10/08/2011 8:02 AM, Henri Yandell wrote:
>>
>> On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu<ce...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Posted by Ceki Gülcü <ce...@qos.ch>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [general] Plexus and Commons code inherited from somewhere else
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-11, Mark Struberg wrote:
> commons-exec is actively maintained by Sigi Goeschl. So at least this
> is known to be in good hands.
I didn't mean to imply it wasn't - or any of the other code that was
forked wasn't properly maintained.
> It's currently in the sandbox, so every ASF committer can contribute
> to it. We are just touching the surface of getting this stuff back to
> the ASF. So any help is welcome :)
> https://svn.apache.org/repos/asf/maven/sandbox/trunk/plexus-utils-commons-bridge
I know, but my plate is currently more than full, sorry.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [general] Plexus and Commons code inherited from somewhere else
Posted by Mark Struberg <st...@yahoo.de>.
commons-exec is actively maintained by Sigi Goeschl. So at least this is known to be in good hands.
The plexus stuff still has @author tags. That's the reason why I learned that you have been involved. I know this also has been discussed highly controversial, but for such fork scenarios the @author tag is really a great thing.
It's currently in the sandbox, so every ASF committer can contribute to it.
We are just touching the surface of getting this stuff back to the ASF. So any help is welcome :)
https://svn.apache.org/repos/asf/maven/sandbox/trunk/plexus-utils-commons-bridge
LieGrue,
strub
--- On Thu, 8/11/11, Stefan Bodewig <bo...@apache.org> wrote:
> From: Stefan Bodewig <bo...@apache.org>
> Subject: Re: [general] Plexus and Commons code inherited from somewhere else
> To: dev@commons.apache.org
> Date: Thursday, August 11, 2011, 9:40 AM
> On 2011-08-11, Mark Struberg wrote:
>
> > I now grabbed the Ant SVN codebase and figured that
> this got imported
> > from CVS in 2004...
>
> Most of the exec, io and compress stuff is older. I
> wrote the initial
> version of the zip package in 2001 and Thomas Haas and
> Conor MacNeill
> did most of the exec things in summer 2000 shortly before
> Ant 1.1, for
> example.
>
> Ant removed @author tags in March 2004 which should give
> you an idea of
> when the split happened.
>
> Let me know if you need help navigating Ant's code.
>
> > Happy to report back fixes, but I'm doing almost a
> blackbox approach
> > for getting the plexus stuff back to the ASF. Of
> course it's ALv1.1
> > licensed, but some folks took the provenience in
> question...
>
> > Our current approach is to write TCK tests for the
> codehaus plexus
> > classes and then implement own versions without
> looking at the
> > original code.
>
> I'm glad I don't share your problems ;-)
>
> Seriously, I am subscribed to maven-dev and was aware of
> what you are
> doing and your approach likely is the best you can do to
> support
> existing plugins.
>
> Stefan
>
> ---------------------------------------------------------------------
> 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
Re: [general] Plexus and Commons code inherited from somewhere else
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-11, Mark Struberg wrote:
> I now grabbed the Ant SVN codebase and figured that this got imported
> from CVS in 2004...
Most of the exec, io and compress stuff is older. I wrote the initial
version of the zip package in 2001 and Thomas Haas and Conor MacNeill
did most of the exec things in summer 2000 shortly before Ant 1.1, for
example.
Ant removed @author tags in March 2004 which should give you an idea of
when the split happened.
Let me know if you need help navigating Ant's code.
> Happy to report back fixes, but I'm doing almost a blackbox approach
> for getting the plexus stuff back to the ASF. Of course it's ALv1.1
> licensed, but some folks took the provenience in question...
> Our current approach is to write TCK tests for the codehaus plexus
> classes and then implement own versions without looking at the
> original code.
I'm glad I don't share your problems ;-)
Seriously, I am subscribed to maven-dev and was aware of what you are
doing and your approach likely is the best you can do to support
existing plugins.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [general] Plexus and Commons code inherited from somewhere else (was Re: [general] Apache + Meritocracy)
Posted by Mark Struberg <st...@yahoo.de>.
Yes, that's the plan. the 'new' plexus-utils FileUtils will for example probably be a slim shim over the commons-io counterpart and just route through.
I now grabbed the Ant SVN codebase and figured that this got imported from CVS in 2004...
Happy to report back fixes, but I'm doing almost a blackbox approach for getting the plexus stuff back to the ASF. Of course it's ALv1.1 licensed, but some folks took the provenience in question...
Our current approach is to write TCK tests for the codehaus plexus classes and then implement own versions without looking at the original code.
LieGrue,
strub
--- On Thu, 8/11/11, Stefan Bodewig <bo...@apache.org> wrote:
> From: Stefan Bodewig <bo...@apache.org>
> Subject: [general] Plexus and Commons code inherited from somewhere else (was Re: [general] Apache + Meritocracy)
> To: dev@commons.apache.org
> Date: Thursday, August 11, 2011, 8:56 AM
> On 2011-08-11, Mark Struberg wrote:
>
> > That's great news and even underlines better what
> Christian already
> > stated: committocracy doen't really work out - not
> socially and not
> > even technically.
>
> No argument from my side.
>
> > The code in question seems to got moved a few times,
> so all commit
> > history is long time gone.
>
> > I'll scan the Ant codebase for similarities and pick
> the stuff I need
> > if that's ok.
>
> Sure this is OK, and I'm sure the Ant community would love
> to get the
> bug fixes that have been applied inside of Plexus as
> well. This doesn't
> have to be a one-way street.
>
> I see this as a general problem with components that
> started off as
> forks from other codebases. There are quite a few
> commons projects that
> have been seeded by code that originally came from Ant,
> Avalon, Struts
> or other places and at least in the case of Ant the code
> bases have
> diverged. Ant has always seen itself as sitting at
> the bottom of the
> dependency stack and thus prefered to not have any
> dependencies at all -
> that's why we've never embraced Commons. On top of
> that nobody told the
> Ant community that their code had been forked and so we
> could not help
> out, but that's water under the bridge.
>
> In the end the same bugs and shortcomings of the same
> original code base
> have been fixed by two or three groups in different ways
> and it would
> certainly be great if we could merge all those collected
> fixes. But
> honestly I dont know how as the focus of the different dev
> groups is too
> different.
>
> At least for your Plexus replacement you should be able to
> leverage what
> is inside of Commons, though.
>
> Stefan
>
> ---------------------------------------------------------------------
> 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
[general] Plexus and Commons code inherited from somewhere else (was Re: [general] Apache + Meritocracy)
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-11, Mark Struberg wrote:
> That's great news and even underlines better what Christian already
> stated: committocracy doen't really work out - not socially and not
> even technically.
No argument from my side.
> The code in question seems to got moved a few times, so all commit
> history is long time gone.
> I'll scan the Ant codebase for similarities and pick the stuff I need
> if that's ok.
Sure this is OK, and I'm sure the Ant community would love to get the
bug fixes that have been applied inside of Plexus as well. This doesn't
have to be a one-way street.
I see this as a general problem with components that started off as
forks from other codebases. There are quite a few commons projects that
have been seeded by code that originally came from Ant, Avalon, Struts
or other places and at least in the case of Ant the code bases have
diverged. Ant has always seen itself as sitting at the bottom of the
dependency stack and thus prefered to not have any dependencies at all -
that's why we've never embraced Commons. On top of that nobody told the
Ant community that their code had been forked and so we could not help
out, but that's water under the bridge.
In the end the same bugs and shortcomings of the same original code base
have been fixed by two or three groups in different ways and it would
certainly be great if we could merge all those collected fixes. But
honestly I dont know how as the focus of the different dev groups is too
different.
At least for your Plexus replacement you should be able to leverage what
is inside of Commons, though.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [general] Apache + Meritocracy
Posted by Mark Struberg <st...@yahoo.de>.
Hi Stefan!
That's great news and even underlines better what Christian already stated: committocracy doen't really work out - not socially and not even technically. The code in question seems to got moved a few times, so all commit history is long time gone.
I'll scan the Ant codebase for similarities and pick the stuff I need if that's ok.
txs and LieGrue,
strub
--- On Thu, 8/11/11, Stefan Bodewig <bo...@apache.org> wrote:
> From: Stefan Bodewig <bo...@apache.org>
> Subject: Re: [general] Apache + Meritocracy
> To: dev@commons.apache.org
> Date: Thursday, August 11, 2011, 1:36 AM
> On 2011-08-11, Mark Struberg wrote:
>
> > 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).
>
> Really? I never contributed to Avalon.
>
> The most likely case is this is code originally written for
> Ant, then
> copied to Avalon from where it was copied to Plexus and
> most likely
> Commons as well. commons-compress' seed as well as
> that of commons-exec
> have taken similar journeys.
>
> You might want to check against the Ant code base to apply
> the bug fixes
> that have piled up over the 10 years that came after Peter
> Donald copied
> the code to Avalon ;-)
>
> Stefan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [general] Apache + Meritocracy
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-08-11, Mark Struberg wrote:
> 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).
Really? I never contributed to Avalon.
The most likely case is this is code originally written for Ant, then
copied to Avalon from where it was copied to Plexus and most likely
Commons as well. commons-compress' seed as well as that of commons-exec
have taken similar journeys.
You might want to check against the Ant code base to apply the bug fixes
that have piled up over the 10 years that came after Peter Donald copied
the code to Avalon ;-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Posted by Mark Struberg <st...@yahoo.de>.
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 <gr...@gmail.com> wrote:
> From: Christian Grobmeier <gr...@gmail.com>
> Subject: Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
> To: "Commons Developers List" <de...@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
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Posted by Christian Grobmeier <gr...@gmail.com>.
> 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
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Posted by Paul Benedict <pb...@apache.org>.
I agree with sebb. I prefer an organization where everyone gets one
vote. This is obviously not the only way an organization can run, but
I like neither having a diminished or overwhelming power with my vote.
The best part of having only +1 is that you can't use your merit to
strong-arm decisions over anyone -- you have to build consensus using
reason. If you can't convince your team, the idea isn't worth doing no
matter how much more voting power you wish you had. I find this
especially equitable since there can be a split of people who do the
work (committers) and vote (PMC). There are some who commit only and
can't vote, others do commit and vote, and others who just vote. Being
on a PMC myself, I am happy my vote is equal to every one else on the
committee.
On Thu, Aug 11, 2011 at 7:00 AM, sebb <se...@gmail.com> wrote:
> Why should my vote carry more weight?
>
> I may have created more SVN revisions than others, but I don't think
> that gives my vote any more value.
>
> Apart from the fact that commit count has little bearing on actual
> work done, and is not an indicator of quality, there are other ways of
> contributing (e.g. mailing list feedback, commit review, release
> testing, bug reporting) that I consider equally valuable.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Posted by sebb <se...@gmail.com>.
On 11 August 2011 10:21, Ceki Gülcü <ce...@qos.ch> wrote:
> On 11/08/2011 8:13 AM, Henri Yandell wrote:
>
>
>> 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]
>
> The person with the most commit points is not necessarily in
> charge. Sebastian Bazley's vote would carry more weight than Henri
Why should my vote carry more weight?
I may have created more SVN revisions than others, but I don't think
that gives my vote any more value.
Apart from the fact that commit count has little bearing on actual
work done, and is not an indicator of quality, there are other ways of
contributing (e.g. mailing list feedback, commit review, release
testing, bug reporting) that I consider equally valuable.
> Yandell's or Simone Tripodi's vote, but Henri and Simone voting
> together would beat Sebastian's *lone* vote every time. It's basic
> arithmetic and I won't insult you with an example containing figures.
>
>> 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.
>
> Yes, committocracy, i.e. decision making based on a commit point
> weighted voting system, does only take into account past
> contributions. Future contributions are ignored until such a time
> where the future becomes the past.
>
>> 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.
>
> Yah, it has been a good discussion. Thanks for your time and input.
>
> --
> Ceki
>
> ---------------------------------------------------------------------
> 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
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Posted by Ceki Gülcü <ce...@qos.ch>.
On 11/08/2011 8:13 AM, Henri Yandell wrote:
> 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]
The person with the most commit points is not necessarily in
charge. Sebastian Bazley's vote would carry more weight than Henri
Yandell's or Simone Tripodi's vote, but Henri and Simone voting
together would beat Sebastian's *lone* vote every time. It's basic
arithmetic and I won't insult you with an example containing figures.
> 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.
Yes, committocracy, i.e. decision making based on a commit point
weighted voting system, does only take into account past
contributions. Future contributions are ignored until such a time
where the future becomes the past.
> 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.
Yah, it has been a good discussion. Thanks for your time and input.
--
Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Posted by Henri Yandell <fl...@gmail.com>.
On Wed, Aug 10, 2011 at 6:06 AM, Ceki Gülcü <ce...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [general] Apache + Meritocracy [Was: [logging] logging vs slf4j]
Posted by Ceki Gülcü <ce...@qos.ch>.
On 10/08/2011 8:02 AM, Henri Yandell wrote:
> On Tue, Aug 9, 2011 at 10:16 AM, Ceki Gulcu<ce...@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.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org