In DeltaSpike and a few other projects I was involved we treated it the following way.
Our initial set of committers consisted of people who either contributed to the original (non-ASF) projects in this area or who are known ASF committers where we did know we could trust in. Additionally to this hurdle, when we graduated we also dropped all committers who have been listed in the incubator proposal but did not actively contribute during incubation. Sometimes we even dropped good folks who we know that they are really great hackers and OSS guys but did not have enough spare time to contribute to the very project. LieGrue, strub ----- Original Message ----- > From: Benson Margulies <bimargul...@gmail.com> > To: "general@incubator.apache.org" <general@incubator.apache.org> > Cc: > Sent: Friday, 27 September 2013, 13:34 > Subject: Re: The podling initial committers issue > > I think that all of this might boil down to the observation, way back > in this thread, that there are different patterns of incoming > projects. > > Some incoming podlings are very small groups of people. If they are > paying attention, they know that attracting new people will be their > biggest problem. Interested, enthusiastic, existing Apache > committers/PMC members/foundation members are exactly what they want. > They aren't a community yet, and starting out with a batch of people > who have some idea how to run one is just fine. > > Other incoming podlings have an existing community. They are willing > to work to adapt that community to Apache norms. We may not have > observed them in their past, but it's reasonable to respect them to > the extent of allowing them to set up shop as themselves and then > bring in others via the usual process. > > Open Office was a special and unusual case on just about every > dimension, so I don't think that it's necessary for every mental > schema to perfectly fit that history. > > It seems to me that the cooler voices here, including particularly > Bertrand, see this whole incident as an unfortunate misunderstanding > over this distinction, and a tiny bit of policy clarification will fix > it, with no further need for rhetoric. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
