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]