meritocracy (was: Re: [MPlayer-cvslog] r22386 - trunk/DOCS/tech/new_policy.txt)

[Diego Biurrun]

On Thu, Mar 01, 2007 at 06:18:48PM +0100, Michael Niedermayer wrote:
> 
> On Thu, Mar 01, 2007 at 05:03:16PM +0200, Ivan Kalvachev wrote:
> > >>
> > >> I don't think that your voting system takes meritocracy into account.
> > >
> > >well, suggest a fair one which does and we can disscuss it
> > 
> > I'll leave that to Mr  Biurrun, who is the one enforcing it.
> 
> IMHO meritocracy the way diego uses the term i think is power to thouse who
> do the work, rather then power to thouse who are best at something, and
> thouse who do the work are the mplayer developers not just 1 or 2 people
> and so it ends as the same as democracy IMHO

No, this is a completely wrong description of what I think meritocracy
is.  Moreover, I think it's a misinterpretation of any definition of the
term.  It's not at all about who is best at something vs. who does the
work.  Quoting Wikipedia:

  Meritocracy is a system of government or other organization based on
  demonstrated ability (merit) and talent rather than by wealth, family
  connections (nepotism), class privilege, cronyism, popularity (as in
  democracy) or other historical determinants of social position and
  political power.

Somebody's standing around here is not measured by educational degrees
and/or the grades received in them.  It is instead determined by the
amount and quality of the work that person has done.

Meritocracy for me means that if you have been doing all the work over
an extended period of time then you should eventually get to make the
decisions, rather than being told what to do by a boss or committee.

This does not mean that you cannot listen to suggestions or that others
have to like what you do.  If they don't, they can always implement a
better solution themselves.  Code wins, not words or formal position.

I became the maintainer of the documentation after doing around 90% of
the work on it.  After I had been doing this for more than a year I was
at some point no longer willing to accept Gabu telling me how to handle
things.  Also, I believe I'm the better technical writer.

Guillaume has taken the MEncoder documentation over from me, Sebastian
the translations.  I offer suggestions and advice, but the final
decisions are theirs, even if I don't like them.

Similar for the MPlayer and FFmpeg build systems.  I became the
maintainer by working on them, learning my way around the code and
because the maintainer position was vacant.  Mans is also the maintainer
of the FFmpeg build system, probably more than myself since he is the
better programmer.  What did he do?  Come along and code.  His shell
magic in FFmpeg configure is a work of beauty.  But since we get along
really well and cooperate well, reviewing each other's code, etc, there
is no need to settle for an exclusive maintainership.

A test to find out who is the real maintainer, or who should be the
maintainer is to ask yourself who could fork (that part of) the code and
whose fork would survive.  If you could not fork, you should not have
the final decisions.  If you could fork, then you should probably be in
charge.

Now where does quality control come into the picture?  It's a separate
issue.  There is no guarantee that you are the best just because you are
working actively on something.  If somebody disagrees, (s)he'll just
have to come up with a better implementation.  Code will decide, not
your money, degree or a badge that reads "manager".

I believe that there is a good correlation between the people working
actively on something and the people best suited to take decisions about
how to implement things.  Much better in any case, than in traditional
commercial software venues run by traditional managers that are
unfamiliar with the technical details.

Motivation is also important.  I work on this, because I like it.  Thus
I should be allowed to do it the way I like it.  There are tradeoffs to
be made here of course, I'm not saying that everybody is free to do as
they please, oh no.  But for example MPlayer has always allowed
individual coding styles for this very reason.

This is getting longish and I have to run out now, but you get the
general idea.  I believe it's very close to the heart and soul of this
project.

> so who was best at being maintainer? i think arpi was better than the
> current root team, thats just my oppinion nothing more and nothing less

This is a logical fallacy.  The current root team is not the project
leader, hence they cannot be worse at being project leader.

> > You use admin more in the sense of project leader.
> 
> hmm maybe i should s/admin/leader/ ?

Yes, project admin and project leader is not the same thing.

Diego