[MPlayer-cvslog] r22386 - trunk/DOCS/tech/new_policy.txt

[Michael Niedermayer]

Hi

On Thu, Mar 01, 2007 at 05:03:16PM +0200, Ivan Kalvachev wrote:
[...]
> >[...]
> >> >+that is yes >= no && yes>0 cast a veto against it
> >> >+Vcc. the votes shall be counted by using the Condorcet/Clone Proof SSD
> >>
> >> Is it this one http://en.wikipedia.org/wiki/Schulze_method ?
> >
> >its the one used by debian, refering to a changeable thing like wiki
> >would be a bad idea for policy
> 
> You'd have to provide detailed explanation of the method (URL by your
> choice) or/and even simple program to calculate the results.
> 
> e.g. I'm sure we would like to know at least what the integer assigned
> to options means. aka smaller number-> preferred option?

ill of course clarify this and add a link


> 
> >[...]
> >>
> >> 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

if it is power to thouse who are best, then the question arrises who is
best and how to decide this and who should decide, of course everyone
thinks (s)he herself is best but that is dictatorship not meritocracy

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
both attila and diego are my friends i just think they are not the best
for the position of the mplayer leader/maintainer

now if you vote on who is best then again you end up with democracy
so meritocracy really is democracy or dictatorship depending on who
decides unless you have some unbiased way of selecting the best, in
some cases that might be possible but i dont think it is for the position
of maintainer/leader


> 
> >> There is also a lot of unclear things - the definition of  admin (e.g.
> >> case where (s)he is root of mphq but not developer)
> >
> >"every admin is also a developer" thats clear IMHO, there are no admins
> >which are not developers that would be inappropriate anyway IMHO
> >a person with such great power over developers should be a developer
> >herself otherwise the person would IMHO simply not be qualified to make
> >decissions over developers
> 
> I also used to think so, but I was proven wrong.
> 
> "every admin is also a developer" is statement, not definition. You do
> not define admin as e.g. "person who have access to the raw
> repository, can add/remove accounts in svn and can do svn admin".
> 
> You use admin more in the sense of project leader.

hmm maybe i should s/admin/leader/ ?


[...]
> >also i dont think we need a rule for that as its clear what to do and
> >something like that didnt happen yet, its more important to deal with
> >thing which do happen
> 
> The issue here is what to do with cases that are not clear violation
> of the existing written rules. Do we vote them? (and would the trojan
> stay until the vote ends).
> Maybe I used too obvious example.

well everyone has svn write access so any single developer could remove the
code this would either lead to a situation in which there is no need to hury
or one where 2 developers repeatly revert each other, i really think attila
or mans would close that persons account in the later case


> 
> >
> 
> There is one more thing I find unclear
> So admins can veto all options except doing nothing?

yes, that is a problem indeed ill try to do something about it

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/attachments/20070301/0373ea8a/attachment.pgp>