oVirt comminuty voting

[Carl Trieloff]

On 09/09/2011 03:40 PM, Anthony Liguori wrote:
> On 09/09/2011 02:29 PM, Carl Trieloff wrote:
>> On 09/09/2011 03:15 PM, Michael D Day wrote:
>>> project-planning-bounces at ovirt.org wrote on 09/09/2011 03:08:17 PM:
>>>> 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.
>>>
>>> I agree that we need to encourage and require more than one maintainer
>>> per project and I like the rule. I don't think we want to force a
>>> change in existing projects that are successful like KVM&  QEMU. In
>>> both of these cases we have projects with a long history of broad
>>> contributions. Or we should recognize that kVM and QEMU have de-facto
>>> sub-mainterships due to the practice of regular almost automatic
>>> pulling of source trees published by key contributors.
>>
>> That seems reasonable. However I think it would be a boost for the
>> respective communities if they voted those key contributors to
>> maintainers if they are defacto trusted and making that recognition
>> public. That in itself is great for all involved, and as from what I
>> understand these key contributors are 'maintainers' in just about every
>> regard except in name and recognition. Formalizing and providing that
>> recognition is never a bad thing.
>
> No, it's formalized already (via a MAINTAINERS file, just like Linux).
>
> Again, this is very similar to other communities like libvirt.  If one
> of the Daniels are on the list, they can comment more, but my
> understand is that there are many people with commit access, but a
> very small number of people that are effectively the benevolent
> dictators and make final decisions on releases.
>
> The main point here is not to debate the effectiveness of any given
> model but to point out that the stricter you are about requiring
> projects to govern themselves in certain ways, the less inclusive the
> overall community will be.
>

apache also has the two levels, they call that the PMC. I stripped the
two levels out to keep it simple and we can update as required. If we
want that we should doc it back in.

goal here is to be transparent and easy for people to join in.

carl