forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Addi <a...@rocktreesky.com>
Subject Re: Simple committership
Date Sun, 07 Aug 2005 14:09:31 GMT
David Crossley wrote:

>Thanks so much for taking the time to reply to
>this important topic. A big effort, i can see.
>
>I am going to reply to this in bits and pieces
>i.e. not all at once tonight.
>
>Please would other members of our community
>(everyone, not just PMC members) also add their view.
>  
>
OK, well, I don't speak much but I do think this is an important topic 
and my work pulling the committer doc together has got my mind wrapped 
around this these days anyway, so here goes.

>More below ...
>
>Thorsten Scherler wrote:
>  
>
>>Nicola Ken Barozzi wrote:
>><snip valuable background information/>
>>    
>>
>> ...snip lots of good discussion...
>
>>My reasoning is that we can ensure that this "newbies" can learn the
>>apache way to it fullest (which is one of the most important point in
>>the process to become a PMC member) without the "pressure" to be an
>>official PMC member.
>>    
>>
>
>But it is a never-ending process. We are all continually
>learning. And most important, that "way" is evolving.
>So for "newbies" (all of us actually), the only way
>is to start walking. There should not be a fence across
>the path which causes us to wait until deemed capable.
>
>It is the mention of "pressure" that i wonder might
>be the key to your concerns.
>
>Apache projects should be fun, no pressure.
>
>I hope that you are aware that as a PMC member,
>or as a developer, you do as much work as you feel
>like doing. You do not need to participate in every
>discussion, just because it concerns the PMC.
>Neither do you need to participate in every vote
>or in every development issue.
>  
>
Maybe this concept should be added to the new committer doc so it is 
stated clearly what the expectations of a comitter are.  I am not 
terribly involved in Forrest at this time, but even I feel guilty when I 
don't have time to read the mail lists or tinker in Forrest for a 
while.  Now, that is part of my personality but I suspect that many 
people who commit themselves to projects like this naturally have a 
similar feeling of responsibilty (and internal pressure).

>The more committers we have, the more pairs of eyes
>are watching the svn diff emails. But every committer
>cannot be expected to notice every problem. Unlax, doc.
>Let the averages work for us. As long as each of us
>do make some little effort, then the whole will work.
>
>  
>
>>New committers have to learn
>>a) "how the Foundation works"
>>b) "how the Project works"
>>
>>One can argue that this should be learned before becoming a committer on
>>the mls but I see a certain process behind it which takes time (some
>>times too much).
>>    
>>
>
>Therefore there should not be a "learn first" situation.
>  
>
While I agree with Thorsten that these are important things to know, I 
don't believe it is a focus limited to committers.  I believe it should 
be something that devs pick up as well and I think that spending a 
decent amount of time on the dev list and really reading what is going 
on serves this purpose maybe more than you think.  See below for more.

>... snip more stuff ...
>  
>
>>I started to use them here on forrest when getting into the
>>documentation for lenya. In lenya we are using forrest to create our
>>documentation and website. We had a custom skin and heaps problems with
>>maintaining it because forrest is developing very rapid. 
>>
>>The lenya skin was nearly all div based. At the time I started here in
>>forrest there was an issue about an "all div based" skin. The result is
>>called "pelt". While I was developing the skin I had "simple
>>committership" to forrest. I am happy that I could concentrate on
>>developing the skin and meanwhile learning all the new responsibilities
>>of a PMC member. After a while I was invited to join the PMC and helping
>>on the long run of forrest. 
>>
>>I could fully participate in the project as committer. I just did not
>>had a counting vote but normally forrest consider every concern. 
>>    
>>
>
>Thankfully we all agreed with your work. It could be
>disastrous if we didn't agree and you had no binding
>vote in the matter.
>  
>
Agreed about the vote.  I think if you are trusted to commit you should 
be trusted to vote.  It only makes sense.  I'll take this space to pipe 
up with my little shout on the whole concept as well.

I see the value in where Thorsten is coming from but it is interesting 
that the focus is on allowing commits but not allowing PMC activity.  If 
the PMC is going to invite someone in as a committer, it seems to me 
that they have looked at that person's work and attitude for a certain 
amount of time and decided that they trust that person enough to let 
them tinker directly with the code.  That is a huge responsibility from 
my perspective and to allow that but not really allow them into the 
project itself strikes me as a little weird.  Sort of giving them a 
direct hand in the DoC part of CoPDoC, but not letting them fully into 
the CoP part. 

If the concern for an incubation place is not code, but project  
management, then why not consider the opposite of the "incubator" being 
proposed and create a PMC incubator where potential committers can be 
given more direct involvement in the project management/infrastructure 
side of things without the right to commit yet?  I don't know how/if 
that could work because obviously I'm not in the PMC and honestly I'm 
not sure what all that entails. 

I am also not entirely sure that I think a distinct incubator is a good 
idea altogether.  It seems to me, that if used properly by the PMC, the 
dev list is already a good place for incubation and assessment of 
potential committers.  A lot is in here if you pay attention.  Perhaps 
taking the mentor role more directly on the list (like when Ross put on 
his mentor hat with Anil) would serve our purposes.  Basically in the 
end noone gets a sense of how a place runs until they step through the 
front door.  The more transparent you make the entrance, by exposing and 
explaining as much as you can on the list, the easier it may be, but it 
will always be a learn as you go thing.

That's my little shout from the peanut gallery.
- Addi

>  
>
>>One thing that helped me is that the PMC normally watch the committs of
>>new committer more careful to ensure that e.g. all legal issues are
>>meet. 
>>
>>PMC membersnot only have to help new committers to learn the duty of a
>>PMC member in the specific project (b) but also like the incubator teach
>>the values of an ASF project and its duties (a). There have been a
>>thread on all PMC lists about the duties (around 10 points) of a PMC
>>member by Davanum Srinivas. 
>>
>>I was given committership to apply my own patches for cocoon, forrest
>>and xml. That leveraged this project (faster process) because other PMC
>>members do not had to do that. Then especially David taught me as well
>>the PMC duties and I became a PMC member. 
>>    
>>
>
>The main reason that there was a delay with you becoming
>a PMC member, was because we had to spend many months
>discussing our project guidelines before we could get
>any new people as PMC members/committers.
>
>Pulling in one of my comments from earlier in this thread:
>  
>
>>>When we look for new committers, we need to see a few
>>>qualities. They should be helping other users and
>>>developers, able to work co-operatively, be a mentor,
>>>and be repectful of others opinions. Essentially be      
>>>committed people who understand the Apache way.
>>>      
>>>
>
>Rather than "understand", i meant: show that they
>have at least some clues and have the potential
>to learn the way. Not expected to know it all yet.
>
>Some people have no idea how to behave in a co-operative
>manner and only have respect for themselves. We do not
>encourage those types.
>
>  
>
>>The important point is that new committer are generally
>>overwhelmed by the information and infrastructure of the project and the
>>ASF. Some learn better step by step understanding what is ASF all about
>>and what a PMC member have to do (I consider myself as such a
>>somebody). 
>>
>>I was lucky and made my experience in the incubator *and* here but the
>>committers we vote in normally do not have this "incubator" experience
>>which I consider most valuable. 
>>    
>>
>
>Take me as a different case. Cocoon was my first real opensource
>project. I had no Incubator to go through. The Cocoon people
>were nice and helpful all the way. But still i had to figure
>most of it out for myself, before and after becoming a committer.
>That is still the case being an ASF member. I still stumble
>in the dark. It is ongoing, and only the committed remain.
>
>  
>
>>>In essence, Jakarta became a small Apache, creating sub-roles where
>>>the
>>>PMC members were like Apache members, and committers were like PMC
>>>members. In Jakarta it's usual that committers vote, but in fact their
>>>vote is not legally valid, and they *cannot* release code without a
>>>PMC
>>>vote.
>>>This also created a big disconnect between the Board of Directors and
>>>Jakarta, and most projects were having little or no oversight, and the
>>>number of Jakarta committers that was an Apache member was extremely
>>>low.
>>>      
>>>
>>The point you are maybe up to is that we can create a closed group that
>>new committer are not able to enter. We limit the PMC membership to a
>>certain group of people for whatever particular reason.
>>
>>The downside is that committers cannot be responsible for the projects
>>because they are not in the "management" PMC. That will slow down the
>>progress of this project(s) because it slow down their processes.
>>
>>I guess it happened because many projects emerged from Jarkata (e.g.
>>tomcat, struts,...) and people felt better in having a good working team
>>then to better leverage their pmc duties in teaching new committer this
>>duties. 
>>
>>One sentence of [2] seems very interesting at this point:
>>"Section 6.3. Project Management Committees.
>>...
>>Each Project Management Committee shall be responsible for the active
>>management of one or more projects identified by resolution of the Board
>>of Directors which may include, without limitation, the creation or
>>maintenance of "open-source" software for distribution to the public at
>>no charge."
>>
>>Now *one or more projects* means that is thought of leveraging not only
>>e.g. jarkata but all sub projects that may emerge. That needs a good
>>working PMC team that can trust each other (most important on legal
>>issues etc.). 
>>    
>>
>
>Sorry i don't understand what you mean about Jakarta.
>
>The "one or more" in the ASF bylaws was to allow scope.
>However the umbrella project concept seems to be
>discouraged now. One PMC, and many committers that are
>not on that PMC, just does not work.
>
>  
>
>>Why are we not adding to the committer role the 'PMC-incubation' label
>>and apply similar rules (we have in the incubator for exiting the
>>incubator cp [3]) to become a PMC member. That will as well make sure
>>that new members will *definitely* enter after "incubation" and overcome
>>the jarkata phenomenon.
>>    
>>
>
>I do not see how we could make such "exit rules".
>It is okay to make rules for projects, but rules
>for measuring people is fraught with difficulty.
>
>  
>
>>In another thread you wrote about becoming PMC/committer:
>>    
>>
>>>"...But we should not try to measure this with an absolute metric:
>>>merit does not earn membership, it earns trust of others members. If
>>>other members trust him based on the contributions, then IMHO there is
>>>all there is to it."
>>>      
>>>
>>I develop trust with time. ...but I can trust somebody to make chances
>>(contributions) and I can trust someone making decisions. 
>>
>>That is a different level of trust we are talking.
>>    
>>
>
>I will need to ponder that before answering.
>
>-David
>
>  
>
>>I consider a clean
>>process of learning about the ASF as better. I started in incubator
>>(with lenya) to learn about the ASF and I still learn everyday.
>>
>>Going from dev to committer and after "PMC-incubation" into the PMC is
>>IMO the best way to develop trust in someone. I think it is better as
>>limited committership or directly enter in the PMC (which normally takes
>>a good amount of time).
>>
>>I hope this "real life" use case shows, that there are persons that will
>>welcome a guided process that as well contain a simple committership
>>"PMC-incubation" role.
>>
>>[1] http://incubator.apache.org/
>>[2] http://www.apache.org/foundation/bylaws.html
>>[3]
>>http://incubator.apache.org/incubation/Incubation_Policy.html#Exitting
>>+the+Incubator
>>-- 
>>thorsten
>>
>>"Together we stand, divided we fall!" 
>>Hey you (Pink Floyd)
>>    
>>
>
>
>
>  
>

Mime
View raw message