river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: Responsibilities of the PPMC
Date Mon, 19 Feb 2007 18:27:38 GMT

On Feb 19, 2007, at 1:03 PM, Craig L Russell wrote:

> 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?

Totally by choice.

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

Well, yeah, I disagree with that statement.  However, a podling is  
free to do this.  But I think it's not a great idea.  First, it's  
counter to ASF convention and tradition.  Second, if you believe that  
being a PMC member requires more "something" than having write access  
to SVN (which is, in it's basest form, what committership means),  
then you are setting a higher bar, and will therefore will add  
committers at a slower rate.

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

Well, I rarely state the former other than in discussion.

>> 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?

Probably not, because it's a personal, subjective judgement, not a  
checklist.  It's also a consensus decision - for example, you may  
suggest that Susan should be on the PMC.  I may have never interacted  
with her, or seen her community building side - I may only see her as  
a brilliant technician.  I'll push back - and you'll provide me with  

Or we may decide that another candidate doesn't "feel" right.

Or lots of situations...

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

No - I think the PPMC/PMC should take an active role in watching  
committers develop into community participants, identify those that  
are participating at a community level, not just a technical one, and  
approach them and offer them PMC membership.

And yes, I think that there is potentially a big difference between  
someone's behavior earning commit, and behavior afterwards,  
especially if the project keeps a low bar for committership (which is  
a good thing...)

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

I don't like that either - i don't like the idea of having people  
ask, because then there's the uncomfortable part of saying "no".  I'd  
much rather encourage (P)PMCs to take an *active* role in this kind  
of community development, rather than re-active, which is what you  
are proposing.

maybe I'm naive - I want to see Apache communities develop a sense of  
independent identity and community, and that actually takes  
committment and effort by those participating.

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