|Re: [eclipse.org-planning-council] RE: [cross-project-issues-dev] Galileo Must-do's|
Hi Richard, Richard Gronback wrote:
Hi Martin,Many of the things we’re requiring are just good Eclipse citizenship items that all projects should be striving for anyway. Globalization effort is not only about larger companies or commercial adopters. At least 2 of the 3 communities that all Eclipse projects are supposed to support require this for worldwide consumption. I see these as Eclipse entry requirements, not only as train requirements. See non-code aspects listed on the Release Review checklist: http://wiki.eclipse.org/Development_Resources/HOWTO/Release_ReviewsI can imagine a larger company contributing to a smaller project to get it up to snuff if they are consumers of the project and require it for a commercial product, for example. But, I doubt you’ll find a willingness to contribute for the sake of getting projects on the release train. Instead, we’ll likely just see smaller projects falling off the train, or the respective project leads growing their project team to meet the requirements, and in the process, improving the overall quality/success of their proje
Rich I feel compelled to respond to some apparent assumptions.First assumption: the stricter rules being proposed imply greater quality of all project's output. Although seeming widely believed in EF...I don't think this is the case for all projects. For example, having a required new and noteworthy (which for my project we've/ECF have adopted happily)...for a project like the platform and others, obviously yes. But for EMF (e.g.), I personally would rather see Ed spend his time on the newsgroup or mailing list answering questions directly with users, or working on his book than writing a new and noteworthy or a dozen plan.xmls. What I'm trying to say is that the *means* to ensure quality (and success for that matter) are based upon a number of things...e.g. how many resources are available, what's the size of the community around the project, what stage of development it's in, what organization is around to help with that community, etc. There's a judgment about what's important for the project and community. One size doesn't fit all projects/communities.
Second assumption: these rules have anything to do with project success. Although it's easy to point to the platform and say 'they were successful, so all projects that do things exactly like the platform will be successful too'...I don't think that's actually the case.
Third assumption: losing small projects [from the train] isn't a significant problem. I think this *is* a big problem, as the small projects are (IMHO) the engine of innovation for Eclipse/Eclipse Foundation. And as much as I would like it to be so, for small companies (and independents) it's not as easy to find contributors...especially from outside the company that leads the project (see our old friend project diversity).
And also: "I can imagine a larger company contributing to a smaller project to get it up to snuff if they are consumers of the project and require it for a commercial product, for example"...I also can imagine it, but regrettably I haven't seen it happen yet.
Back to the top