On 03/31/2015 06:24 PM, John Griffith wrote:
What is missing for me here however is "who picks these special people". I'm
convinced that this does more to promote the idea of "special" contributors than
anything else. Maybe that's actually what you want, but it seemed based on your
message that wasn't the case.
Anyway, core nominations are fairly objective in my opinion and is *mostly*
based on number of reviews and perceived quality of those reviews (measured
somewhat by disagreement rates etc). What are the metrics for this special
group of folks that you're proposing we empower and title as maintainers? Do I
get to be a "maintainer", is it reserved for a special group of people, a
specific company? What's the criteria? Do *you* get to be a "maintainer"?
What standards are *Maintainers* held to? Who/How do we decide he/she is doing
their job? Are there any rules about representation and interests (keeping the
team of people balanced). What about the work by those "maintainers" that
introduces more/new bugs?
I think Joe's comments about giving more people more responsibility make a lot
of sense.
I worked with the Linux kernel more-or-less professionally for about a decade,
and while the kernel project has its problems there were a things about its
maintainer model that I liked.
1) There was a MAINTAINERS file at the top level in the source, listing who was
currently responsible for what areas of code, along with their contact
information. Generally this was one or two people, with larger subsystems
having a mailing list as well.
2) The maintainers were generally chosen by consensus because they were the
experts in that area, they had time available, and they were willing to take on
the task. Usually when a maintainer stepped down there was someone to take
their place who had been working closely with them for some time.
3) If you found a bug in a particular area, you could look up that area and find
out who was in charge and take the problem to them. Similarly, if you wanted to
contribute some code in a particular area there was a relatively small number of
specific people that you could to talk to about whether the change made sense,
or what modifications would be needed to get it accepted.
I think some of this exists informally within OpenStack, but it's not obvious to
a newcomer who they need to talk to if they have an issue with libvirt, or with
the scheduler, or with the DB, or some minutiae of the REST API. (Sorry for the
nova-specific examples, it's where I've spent most of my time.)
I don't know what sort of process would be appropriate for selecting these
people within OpenStack, but I think it would be useful to follow Joe's
suggestion and give people approval privileges within a subsection. It's *hard*
to find people that are able to wrap their heads around the entirety of
something like nova. I suspect it would be easier to find people willing to own
a smaller piece of the code.
Chris
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
