Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # dev >> PMC member criteria for ZooKeeper.

Copy link to this message
Re: PMC member criteria for ZooKeeper.
yes, overall i agree with your response to mahadev. i think in the
case of zookeeper we want pmc members who are familiar with the
project since they are voting on releases and release planning. they
also vote on committers. this is a bit different than the IPMC which
has a large collection of unrelated projects. since zookeeper has a
much more focused scope familiarity with the project is important.


On Tue, Mar 8, 2011 at 8:47 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> Ben, what you are detailing is similar to my response to Mahadev. One
> note though, from an Apache perspective PMC members need not even be
> familiar with the project, take Hadoop as an example where Ian was
> largely unfamiliar with Hadoop prior to joining their PMC.
> legal/procedure/community building, these are all things that can be
> done by someone familiar with the apache way, but not necessarily
> familiar with the individual project (not that I'm advocating we pull
> in non-zk community into the pmc, but just to highlight).
> Another example is the IPMC (incubator pmc), any Apache Member may be
> an IPMC member just by asking, and they are charged with the oversight
> of the individual podlings.
> Patrick
> On Mon, Mar 7, 2011 at 3:12 PM, Benjamin Reed <[EMAIL PROTECTED]> wrote:
>> i would like to the pmc to have more of a project management view. i
>> think it would be great to have pmc members come up through the
>> committer ranks, but i also think there may be potential pmc members
>> that are more project management oriented than code oriented.
>> for me an ideal pmc member would:
>>  - understand the project
>>  - have a good understanding for where the project should and
>> shouldn't go, and be able to express that understanding
>>  - should vote on releases and be involved in release discussions
>>  - should participate in the mailing lists
>>  - have a good view of how zookeeper sits in the apache eco system
>>  - know what work is going on and identify areas of needed work
>> a committer will do many of these things, but you could be the ideal
>> pmc member and not be heavily involved in the coding, so making the
>> pmc members a subset of the committers seems overly restrictive.
>> actually it may be nice to have some members who don't have their
>> heads down in the code so that they can take a broader view.
>> so i guess the one attribute i would take issue with from your list is
>> the "patch reviews and contributions". a pmc member should be familiar
>> with the work going on in the project, but "patch reviews and
>> contributions" is squarely in the committers area of responsibility.
>> ben
>> On Mon, Mar 7, 2011 at 9:00 AM, Mahadev Konar <[EMAIL PROTECTED]> wrote:
>>> Hi all,
>>>  I have been thinking about what should be the criteria for PMC
>>> members for ZK. I do not have much experience with PMC member criteria
>>> for other projects except for Hadoop. In Hadoop we indirectly imply
>>> that a PMC member be a superset of a committer. Meaning more
>>> responsibilities than a committer, more responsibility towards project
>>> direction, more responsibilities towards projects day to day
>>> activities.
>>>  and here is what I had in mind for ZK (mostly explicitly stating what
>>> we have in Hadoop):
>>> A PMC member should be able to get involved in the day to day
>>> activities of the project
>>>   - by day to day activities I imply
>>>      -  release discussions
>>>     -  code reviews/ could be any kind - documentation/ others (does
>>> not imply a deep understanding of the project), should be willing to
>>> contribute on any part of the project
>>>     -  should be willing to work with new contributors and mentor
>>> them (mostly a superset of committer).
>>>  - works well with other PMC members
>>> By the above I imply that a PMC member has a greater set of
>>> responsibilities that a committer and should be able to review (any
>>> contribution) and contribute towards ZK releases.