Re: [eclipse.org-planning-council] RE: [cross-project-issues-dev] Galile

[Richard Gronback <richard.gronback@xxxxxxxxxxx>]

Just imagine how many New & Noteworthy pages we all could have written in
the time spent on this discussion ;)  This conversation illustrates why I've
been trying to bring us back to the defined model of project -> PMC ->
Planning Council.  I'd much rather be working on the Galileo builder than
trying to rationalize each requirement with everyone in the community.

Anyway, to address your assumptions on the assumptions:

> First assumption: the stricter rules being proposed imply greater
> quality of all project's output.
> ... 
> There's a judgment about what's important for the project and community.
> One size doesn't fit all projects/communities.

Right, and it was the judgment of those on the Planning Council that the
published requirements were beneficial to the majority of those involved.
Again, not my personal judgment, but the judgment of those who participated.
We're never going to get 100% buy-in from all stakeholders on any item, I
suspect.  Should we instead settle for the least common denominator for what
all projects can achieve and see what that train looks like?

> 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.

An interesting argument.  I don't think we're at all saying that if you do
these things you will be successful, only that if you do these things you'll
be on the train ;)  One goal we're hoping to achieve is a higher degree of
consistency, if not quality, among train participants.  We don't promise
success to a project, but do set expectations for consumers on what to
expect from all train projects.

> 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.

An unfair assumption, though I'd argue that the "engine of innovation" will
continue to run even if derailed from the release train.  Tell me, what
major advantage do projects derive from train participation?  I don't know
that I understand the connection between the two.  Are you saying that these
smaller projects require train participation to succeed?  Seems somewhat
contradictory to your second assumption.

- Rich




On 11/14/08 1:05 PM, "Scott Lewis" <slewis@xxxxxxxxxxxxx> wrote:

> 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_Reviews
>> 
>> 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. 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.
> 
> Scott
> 
> 
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>