Berin Loritsch wrote:
From: Stepanossov, Kirill [mailto:[EMAIL PROTECTED]]Sorry for noise here... Its not noise.
Yup, highly appreciated :-)
but it looks both Berin and Stephen are right - the existence of veto as
well as majority voting can be abused and both your justification are
correct. Well... one of you is optimistic the other one is pessimistic with
regards to "ability" of Avalon community and its developers... so why
wouldn't you just look at what/who you have now in board and then based on
that knowledge come to compromise conclusion... or just assign a
person("judge"?) who should decide if the veto is valid in arguments ?
Third option is that we agree on 2/3 majority. I am against blind majority (i.e. with 4 for and 3 against a motion gets passed even if the objections are really good and showstoppers). Steven is against unanimous (i.e. with 34 for and 1 against a motion gets vetoed even if the objection is poorly stated). With 2/3 majority and a quorum of 9 people, if you have 6 for and 3 against the motion gets passed. I also stipulated that the voting time is open for a whole week. That leaves room for the nay sayers to voice their opinion and possibly sway the vote, although at that point it is more likely that the nay sayers vote will be swayed. It also leaves room to have time to think thoroughly about a proposal and have a good feeling after the voting is closed.
Actually we have had a very interesting and long discussion on the incubator general list on the veto-deadlock issue.
At one point Ken Coar came out with a very long and clear mail on the subject and the thread came to an end, so I see it basically as something we agreed on. I'm including here parts of that mail that are relevant.
Please read it all, it is very important.
Rodent of Unusual Size wrote:
>
> Nicola Ken Barozzi wrote:
[...]
>>This really disturbs me, the fact that when these things
>>arise there are no rules I am aware of that are used in
>>not keeping the community at the mercy of these guys.
>
> the rules exist. either a veto is valid and the item being
> vetoed must submit, or it is *not* valid and the vetoer
> is the one who must submit. it is up to the community to
> enforce these rules, either through peer pressure or possibly
> the extreme step of suspension of privileges.
>
> according to the structure of the foundation, it would be
> reasonable to bring cases like this to the pmc for a decision.
> if none is forthcoming, the chair of the pmc, who is the
> officer of the foundation in charge of the project, may make
> a determination. failing that, the issue could be brought
> to the board, which is the final authority. even that is
> not completely final, since members can elect different directors
> and re-raise the issue. such an occurrence would be a severe
> pathology, however.
[...]
>>>commit access is a privilege, not a right. if someone uses
>>>vetos capriciously -- or ignores them -- despite warnings,
>>>the suspension or revocation of commit privileges should
>>>definitely be considered as an option.
>>
>>Again, *who* decides it?
>>*Who* can propose it?
>>*How* should it be voted?
>
>
> ultimately, the foundation officer in charge of the project.
> who, as i said, will probably work frantically to keep it
> from landing in its lap, and will try to come to some pathway
> that is best for and most acceptable to the community.
>
> what follows is my opinion, based on intimate experience. i
> believe it to be an accurate portrayal of reality. i could be
> mistaken, and i hope roy and others will correct me if so.
>
>
>>But it still smells like benevolent dictatorship...
>
>
> in a way it is. be very clear on this. it is not a demoncracy.
> there is a very definite structure of authority and responsibility.
> the code belongs to the foundation. the foundation is the
> members. the members elect the board to oversee the foundation
> and ensure its continued existence and health. the board appoints
> officers to oversee and be responsible for projects. these officers
> are ex officio chairs of the projects' management committees.
> beyond that point, the structure becomes more diverse on a
> project-by-project basis, since how each pmc will 'manage' its
> project is something it and the chair will develop that, in
> their opinions, is best for the project and the community.
>
> it is a balancing effort. the only rights here are those invested
> in the members, who comprise the foundation. the board serves
> at the pleasure of the members; the pmcs serve at the pleasure
> of the board. that is the top-down authoritarian legal view.
> balanced against that is that the only way the foundation will
> continue and succeed is by having healthy communities; healthy
> communities mean committers who are [mostly] content. which
> means that the board and the pmcs can only fulfill their functions
> by supporting the committers. the factors of 'contentment' include
> (but are not necessarily limited to) 'let me work on the code without
> joggling my elbow,' 'provide me the tools and infrastructure i need
> to work on the code,' and 'provide me an environment of peers in
> which i can have fun.' therefore, the foundation guidelines -- and
> each projects' -- are (or should be) geared to satisfy these needs
> in the most constructive (or least destructive) way that can be
> devised.
>
> <digression>
> which raises another interesting point. i think no-one will
> dispute that there are people who are better qualified than
> others to do <random technical magic>. however, when it comes
> to figuring out how to make lots of people 'play nice' and
> constructively together, it seems everyone considers itself
> an expert.
>
> well, not everyone. some people, myself included, recognise
> that as a talent or acquired skill, and, deep down, realise that
> there are people better qualified in that area than ourselves --
> even if we have difficulty admitting it publicly or even to
> ourselves.
> </digression>
>
> i think what has been missing here is not the structure, but
> *awareness* of it and its significance.
>
> okey, i've sounded off on my opinion enough, i think. i'll
> go don my asbestos environment suit now.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
