oVirt comminuty voting

[Carl Trieloff]

On 09/11/2011 03:57 AM, Itamar Heim wrote:
>
>> -----Original Message-----
>> From: project-planning-bounces at ovirt.org
> [mailto:project-planning-bounces at ovirt.org] On Behalf Of Anthony
>> Liguori
>> Sent: Friday, September 09, 2011 23:39 PM
>> To: cctrieloff at redhat.com
>> Cc: project-planning at 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.


I'll draft a first version of the becoming a sub-project doc, and I'll
try work this feedback into that.

Carl.