river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Responsibilities of the PPMC
Date Mon, 19 Feb 2007 18:03:42 GMT
I changed the alias of this message back to the incubator, because I  
think it's back to a more general discussion.

On Feb 19, 2007, at 9:37 AM, Geir Magnusson Jr. wrote:

> On Feb 19, 2007, at 11:41 AM, Craig L Russell wrote:
>> On Feb 18, 2007, at 6:40 PM, John McClain wrote:
>>> I think "reasonably high bar for commit to ensure working social  
>>> and technical compatibility, and then faster PMC" is a reasonable  
>>> place to start (understanding that it may well be imposable to  
>>> change once we start....)
>> The suggestion has been made that a good policy for a PMC (and by  
>> extension a PPMC) is to have all committers who have the time to  
>> do so to become members of the PMC as well.
> yes - the PMC is the "core governance unit" of a project in that  
> only PMC members have a binding vote.  So the goal then should be  
> to get all committers on the PMC.
>> Geir expresses a different opinion, if I'm reading correctly. He  
>> suggests that committers not become PMC at the same time but later  
>> ("faster PMC").
> What is my "opinion" different from?
> I believe that all committers should be on the PMC.  That doesn't  
> necessarily mean immediately.

It's the "immediately" that's the crux of the question.
> I can't think of any projects where committership == PMC membership.

By choice or by accident?

> For example, mechanically a person can get committership based on  
> the PMC's whim, but at the end of the day, PMC membership is  
> subject to board oversight.
>> I'd like to understand what extra demonstration of commitment a  
>> committer should have in order to become a member of PMC. To me,  
>> the relatively high bar of committer plus willingness to serve  
>> should be sufficient.
>> Did I capture the essence of the distinction, Geir?
> I don't have the slightest idea where you are going here.

What I'm trying to do is to come up with a statement that can be put  
into the Incubator guides on PPMC roles and responsibilities (see the  
original email of this thread). I missed with my first attempt, which  
is, "Podlings are encouraged to make all committers members of the  
Podling's PPMC. Thus, the vote to accept a new committer should also  
be a vote to accept a new member of the PPMC. " I need to reword this  
if the committer vote and the PPMC membership vote are not the same.
> Projects choose the level of participation they look for before  
> offering someone committership (which varies in factors such as  
> skill, engagement and time).
> Also, they could choose to offer that person PMC membership at that  
> time, or they may choose to wait - it's not unreasonable to believe  
> that people's behavior may change once they are granted commit  
> rights, as it changes the social equation.
> I actually go back and forth on this one -

It's the back and forth that I was calling attention to.

> I can convince myself that there should be no committer w/o binding  
> vote (iow, must be on the PMC), but OTOH, there are well  
> articulated reasons for letting there be interactions as  
> "committers peers" before granting PMC membership.  Therefore, I  
> stick with the POV that "all committers that want to should be on  
> the PMC, eventually".

So you want a committer vote by the PMC, followed some time afterward  
by a PMC membership vote. What I'm still missing is the "well  
articulated reasons for letting there be interactions as "committers  
peers" before granting PMC membership". Are the reasons enumerated  
somewhere? Is the guideline simply to check back with a committer  
after some time period and see if they are interested in becoming a  
member of the PPMC? Should the only thing be whether a committer  
requests PMC membership? I also go back and forth on what a recently  
voted committer on a project would to to change anyone's impression  
that they should become a member of the PPMC.

I started with something like this, but don't like the way it sounded:

It should be a goal of a project to have all committers participate  
in the PPMC. A committer who expresses interest in the governance of  
the project should ask to become part of the PPMC. Membership in the  
PPMC should be gated by continued commitment to the project and an  
expressed interest in PPMC membership.
> However, no matter what the system chosen by the PMC, I believe  
> that there shouldn't be a structured "caste" system - treat all  
> committers as equal, and if you ever need to count the official PMC  
> votes to make a decision, stand back and figure out why you need to  
> do so, because there may be a big problem :)

No issue there.


> geir
>> Craig
>>> I think "initial committer list == initial PPMC" is fine too.
>>> Jim Hurley wrote:
>>>> I am +1 for this position/proposal.  Can others on the list
>>>> please state your opinion (I think this will be a healthy
>>>> activity for us).
>>>> Geir - I am assuming that we're going to make
>>>> initial committer list == initial PPMC, though.  Cool
>>>> with that?
>>>> thanks -Jim
>>>> On Feb 16, 2007, at 5:21 AM, Geir Magnusson Jr. wrote:
>>>>> On Feb 16, 2007, at 5:14 AM, Mark Brouwer wrote:
>>>>>> Geir Magnusson Jr. wrote:
>>>>>>> My personal taste lately is a reasonably high bar for commit
>>>>>>> to ensure working social and technical compatibility, and  
>>>>>>> then faster PMC.
>>>>>> Given the nature of the ASF and the high quality and  
>>>>>> consistency of the
>>>>>> codebase brought in I'm inclined to go for you personal taste.
>>>>>> In theory it might be possible to come up with a completely  
>>>>>> different
>>>>>> process that would be a better fit, but for me it will be a  
>>>>>> waste of
>>>>>> time to start thinking of that and why not try something that  
>>>>>> has proven
>>>>>> itself on a few occasions.
>>>>> But note that the bar isn't really that high overall - to me  
>>>>> it's more about social compatibility than technical prowess,  
>>>>> because someone who understands their limits, works well with  
>>>>> others, and is willing to learn is a treasure :)
>>>>> geir
>>>>>> --Mark
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/ 
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message