oVirt comminuty voting

[Carl Trieloff]

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:
> > > 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.
>
> 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.

However, I agree, with these listed projects we can make it happen.

Carl.