RE: oVirt comminuty voting
-----Original Message-----
From: project-planning-bounces(a)ovirt.org
[mailto:project-planning-bounces@ovirt.org] On Behalf Of Anthony
Liguori
Sent: Friday, September 09, 2011 23:39 PM
To: cctrieloff(a)redhat.com
Cc: project-planning(a)ovirt.org
Subject: Re: oVirt comminuty voting
On 09/09/2011 03:03 PM, Carl Trieloff wrote:
> On 09/09/2011 04:00 PM, Anthony Liguori wrote:
>>
>> I'd prefer something like, communities with greater than 3 (or maybe
>> 10?) maintainers can creator their own voting procedures.
>
> that is what apache does btw and is fine by me. the goal here is to
get
> a broad maintainer set and help mew projects grow. once a
project has
a
> good culture, they can evolve it themselves.
Okay, that sounds good. Perhaps we should try to work language like
this into more of these docs? Basically, three tiers of projects:
Tier 0; x < 3 maintainers, oVirt board has ability to make decisions
on behalf of the project.
Tier 1; 3 <= x < 10 maintainers, project is autonomous, but must use
oVirt recommended voting procedures and maintainership model.
Tier 2; x >= 10 maintainers, project is autonomous and writes its own
governance document. Perhaps the document should be voted on by the
oVirt board?
I think that creates a nice incubator model where oVirt helps a project
grow and gets out of the way once it reaches critical mass.
Can anyone give me an idea of where the initial set of seed projects
will fit? How many maintainers is oVirt Server likely to have? (I
assume that's the biggest of the seed projects).
I think the comment on a 'leader' and the need for a tie breaker is valid
for projects with less than 10 maintainers as well.
This is also relevant for overruling a nack to avoid stagnation. A
majority of acks, or leader as tie breaker should be able to vote on
overruling a nack.