Let me see if I can summarize some of the issues as I see them...

Currently,  new podlings come from one of three sources:
1) Closed source code (usually from and external company) that is useful and 
thus would like to be made open source.  (tuscany, yoko, etc...)
2) One (or more) open source communities wanting to move their project to 
Apache.  (CXF, Wicket, etc...)
3) Completely ground up, no code yet exists, ideas to be complete built in 
apache.

All three have a different set of initial concerns that I think we all need to 
think about.    I don't know enough about the 3rd case so I cannot comment on 
it.   Does that even happen?   Or is it mostly some code exists somewhere?


For case (2) - there are public communities that exist with commiters, 
effective PMC's, etc...   We should definitely leverage those and move those 
lists along with the code whenever possible.   However, the thing that I've 
seen recently is during the proposals a LOT more people are added onto the 
initial commiter list than have earned commit access in the other community.   
To me, that is the the problem.   If they didn't earn it there, why should we 
give it to them "for free"?    Thus, for (2), I would suggest just commiters 
from the external project(s) and no others for the initial bootstrap list.   
I'd like to see something mentioned about "inactive commiters" from the other 
projects, but the PPMC could deal with that in incubation or upon graduation.   
One thought would be to ask each of the commiters on those projects if they 
want to be commiters on the new one at apache.    If yes, then add them.  If 
they say no, no harm done.    Some people may actually prefer not to be 
apache commiters.  Taking the CXF proposal for example (I was involved with 
this one so I'm just as guilty as anyone here):  of the 34 proposed initial 
commiters, I think 8-10 of them had not been commiters at either Celtix or 
XFire.   Another 5 or 6 or so would be in the "inactive" category.


For case (1), there doesn't exist a community already except for within a 
single company.  If we just go with "those who have worked on the code" as 
initial commiters, they'd all be from one company.  (not that I'm saying 
that's bad for a start in the incubator.   I'm actually 100% OK with that.  
To me, that's a good thing.)  However, going the other way of throwing on 20+ 
commiters that have yet to even see the code is probably not good.   Again, 
to me, that's giving out karma like it's candy.   Anyone who asks during the 
proposal phase gets it without any other criteria.     Unfortunately, lately, 
it seems like there are more of the later case of throwing on people that 
express any interest.   Personally, IMO, I'd like the initial commit list to 
be ONLY those who have seen the code, and in the incubator, they can 
completely build their community.   I COULD see adding other "industry 
experts" (example: if the project is implementing a spec, having some of the 
spec reps on the project might be OK to help direct it), but even then, I 
don't see the downside of having them earn it.

Anyway, I'm not sure of the "right" approach for dealing with (1).   I would 
say that in all three cases, the incubator PMC needs to do a better job of 
reviewing the commiter lists before the vote.  

Basically, I'd like to know:
1) Why are projects being submitted with 20-40 initial commiters?   Most of 
the successful projects in apache don't have that many.   The barrier to 
getting accepted at apache is supposed to be very low.   To me, 3-5 commiters 
should be more than adequate.   One the PPMC is setup, they can quickly and 
easily "grow" their community.   That's not a problem.    It's easier, and 
certainly produces less arguments, to grow a community than to remove people 
that don't belong.

2) What's the downside of having people in the incubator projects actually 
earn the commit rights instead of giving it freely?   If normal apache 
projects grow their community through contributions, why shouldn't a podling 
try and act like a normal apache project?    The "recent trend" of giving 
everyone commit access immediately, to me, has more downsides.   It doesn't 
follow the apache meritorious processes and it can also cause the community 
to fracture if corrective action is taken.    I really don't like the "PPMC 
can correct it in incubation" idea.    From this whole thread, you can see 
that the major effect this has is to splinter the community, causes heated 
discussions, pisses people off, etc....     If a project/podling can start 
off on the right foot, there would be a much better experience.

Of course, I'm not an incubator PMC member so my opinion definitely doesn't 
bind to a vote and I don't have the years of experience and expertise, this 
is just based on my (limited) experience so far.  

Enjoy!
Dan



On Monday October 02 2006 8:42 am, Jim Jagielski wrote:
> On Oct 1, 2006, at 5:17 PM, Justin Erenkrantz wrote:
> > On 10/1/06, Dan Diephouse <[EMAIL PROTECTED]> wrote:
> >> would however encourage only voting people in after they an
> >> appropriate
> >> level of committment and involvement with the project.
> >
> > This creates a dividing line by omitting past contributions from the
> > discussion which I feel is inappropriate.
> >
> > For example, if I were to work on a project for many months at
> > Google Code
> > and then propose it to come here, why shouldn't I continue to have
> > a say in
> > what the project does?  Why do I need to justify myself all over
> > again?  Why
> > aren't my past contributions enough to merit a seat on the PPMC?
> > What gives
> > the mentors the power to 'reset' the community and block me from
> > participating until I jump through their vague and ill-defined
> > hoops?  --
> > justin
>
> ++1. If the problem is "piling on" in the committer list
> for the proposal *then that should be addressed at the
> proposal timeframe and before the podling is accepted*!
>
> As mentioned in a different Email, I'm +1 on adding
> in, in the proposal: Mentors | Initial PPMC | Initial
> Committers if people want it explicit, but no matter
> what, this should be handled before podlings are
> accepted, not after.
>
> I think that issue is that some Mentors have different
> feelings from what is documented... Recall, after all,
> that people from the outside ONLY have access to
> what is documented, not our internal discussions...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
Daniel Kulp
[EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to