I suppose if a new product + its community want to become part of a PMC, coding could happen under that PMC (so for example: in a branch of their repository, releases require 3 +1's by that PMC), but with IPMC or comdev watching from the sidelines and helping if needed.
Over at Subversion we once solicited comdev input on a community issue surrounding a potential GSoC volunteer. That's the same pattern: coding parts handled by the TLP and advice on community issues by comdev|incubator. Mattmann, Chris A (388J) wrote on Sat, Mar 02, 2013 at 05:02:37 +0000: > Hi Niall, and Greg, > > Just to echo Greg, +1, yes would have preferred it to have happened in the > existing > community then. > > Also, agree with Greg -- exceptions can be permitted from time to time, > but I don't think > graduation into existing TLP should be an accepted norm. > > Cheers, > Chris > > On 3/1/13 8:55 PM, "Greg Stein" <gst...@gmail.com> wrote: > > >On Mar 1, 2013 8:33 PM, "Niall Pemberton" <niall.pember...@gmail.com> > >wrote: > >> > >> On Tue, Feb 26, 2013 at 9:52 PM, Greg Stein <gst...@gmail.com> wrote: > >> > I concur with Chris, and want to strengthen/meta the point. The > >Incubator > >> > should not be used for projects which are intended to become part of > >>an > >> > existing TLP. The Incubator *creates* Apache-style communities. But... > >Stop. > >> > > >> > For these, we don't want a separate/new community. They are supposed > >>to > >be > >> > *part of* the existing TLP. Thus, they have no business here. They > >should > >> > start within the target TLP. > >> > >> The incubation of WebWork into Struts is an example where there was an > >> existing project outside the ASF with an existing bunch of developers > >> that were not ASF committers. The point of going through the incubator > >> was for the communities to merge. I guess at the time we could have > >> just given comitt access to all WebWork devs - but most of us on the > >> Struts project didn't know them. Is that what you're proposing should > >> happen in this scenario? > > > >Yup. > > > >The Incubator doesn't have "staff". It really doesn't make sense to put a > >community in their hands. Either a community self-builds, or it should > >become part of an existing community. > > > >For the WebWorks case, I would rather have seen them get a branch in > >Struts. Over time, the features would get integrated from the branch to > >trunk, and the committers would get expanded commit access. > > > >I understand a project may arrive, thinking to become a TLP, but later > >change their desired exit. But I think it would be best to call that an > >exception. Instead, we let target communities directly teach the incomers > >about operating within their (our ASF-style) community. > > > >Cheers, > >-g > > > --------------------------------------------------------------------- > 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