oVirt comminuty voting

[Carl Trieloff]

On 09/09/2011 02:48 PM, Anthony Liguori wrote:
> On 09/09/2011 01:08 PM, Carl Trieloff wrote:
>>
>>
>> Please read, we can always vote in updates, so proof it and make sure it
>> is good enough to get going with.
>>
>> (URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
>>
>>
>> Jim, if you also proof, given your experience in this area
>>
>> I have linked it into the web site layout in the google doc, I'll be
>> working all the key sections one by one to get us going for launch.
>
> I assume code doesn't mean code as in software, but some sort of
> community code?
>
> One concern I have is that this seems to enforce that all projects are
> managed via consensus.  But many existing (and successful) Open Source
> projects don't use an Apache-style consensus model but rather rely on
> a benevolent dictatorship or some variation thereof.
>
> I think it's fine to use a consensus model for oVirt business, but I
> think it's important to allow sub projects to use other types of
> leadership models.  Otherwise you're excluding large parts of the
> existing community, most notably, libvirt, QEMU, and KVM.
>
> So I think for project specific things (like whether a project is
> ready for a release) needs to be completely deferred to the sub project.
>
> If the sub project needs to somehow codify how it makes decisions,
> that's fine, but the sub project should ultimately have the say over
> how it makes decisions. 


The goal is for each sub-project to get to 3 or more maintainers, which
rules out the benevolent dictatorship model for sub-projects. The goal
here is to build a growing and sustainable community not reliant on
single individuals.

Think of it as at least three benevolent dictators per sub-project, or
if the project has less than three, the board helps provide
accountability. For projects like KVM, QEMU, libvirt, if they joined in
we would encourage them vote on additional maintainers. It is hard to
argue any downside to doing that.

Carl.