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.