On 8/7/05, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: > On 8/7/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > > > Please note that although we have attempted to establish a balanced policy, > > it is not our goal to have widespread adoption of projects that are still in > > the Incubator. We want projects to be making a focused effort to get out of > > the Incubator. > > To me, that's a contradiction. "Widespread adoption" will help > building a community. Which is clearly a primary goal of most projects > in incubation.
I agree with Jochen on this. I hesitate to bring this subject up yet again, but since it has been one of my pet concerns in the past: There have been times when the Incubator PMC has defined the bar for graduation to include (in addition to the legal check, the logistics, and the general Apache-style community) strong user adoption and a very diverse set of committers. The "diverse set of committers" has sometimes been defined as not only the three independent committers, but also the requirement that no single committer (or single employer of many committers) is critical to the project. Obviously it is much easier to get to this state if the project isn't being limited in what it can release. In addition, this requirement for graduation could take quite a while for some large project, during which time they might want to actually do an official v 1.0 or 2.0 release. I have proposed in the past (and gotten consensus) that incubating projects can do full official releases, as long as they follow the incubating brand guidelines, which include labeling the download filenames with the word "incubating" and inserting the disclaimer statement in the README. However, many on the PMC would rather not see formal releases while in incubation; instead, they would rather see the project graduate sooner without the hard-line requirement for a strong/diverse user/dev community. So, here's what it appears we are telling new projects (roughly sequential phases): 1. ensure there are no legal issues as soon as you enter incubation 2. figure out the logistics of mailing lists, bug tracking, source repositories, etc at the same time 3. release only snapshot-style distributions as needed, as long as they follow the incubator branding guidelines. No official releases are allowed. Nothing that resembles a normal Apache product release. 4. bring on enough committers to ensure there are at least three working for independent interests (the releases described in 3. should be enough to get this point done) 5. ensure you've built a healthy user and developer community. Healthy user community = some user interest manifesting itself on a mailing list. Healthy developer community = evidence of following a consensus-based, meritocratic development style and responding to the user community, but no requirement that one committer (or many committers working for one employer) can't be doing 95% of the commits. 6. after making sure any remaining issues on the incubation checklist are complete, request graduation. Note that 1-6 must happen before the project's user/dev community feels it's time to put out an official release. IMO, if the Incubator PMC intends for step 5 to be defined in stronger terms, we need to be a little more flexible with projects that want to do releases. Cliff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
