[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] RE: [cross-project-issues-dev] Galileo Must-do's 
Hi Rich,

Richard Gronback wrote:
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.

I'm not so sure that's a good idea. That is...adding hierarchy doesn't typically improve representation IMHO.

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.

Right. And how many project leads of small projects are on the planning council? (I'm not trying to degrade this as 'us vs. them' in any way, but I do believe smaller projects are under-represented on the planning council).


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?

That seems like a potential improvement to me.


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 ;)

Well, I would guess that the benefit to the projects of the train is mostly around getting/improving distribution, usage, exposure, creating/building community. There are obviously other things, but from the project lead point of view this seems to be the main one.

So from my/project lead's/committers point of view, being on the train is a material aid to success...unless it becomes undoable because the council, Board, Foundation or whoever 'charges' too much (i.e. in committer's time to satisfy all requirements).


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.

I think that would be great. But it seems to me that that would imply simply enforcing/helping to implement the existing rules rather than adding new ones.

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.

Perhaps you are right...but an organizational-level bet that I would personally not want to make.

RE: unfair assumption...ymmv I suppose.


Tell me, what
major advantage do projects derive from train participation?

I think I'm repeating as above: exposure, usage, adoption and the resulting community building.

I don't know
that I understand the connection between the two. Are you saying that these
smaller projects require train participation to succeed?

No, I'm not saying they require it to succeed, but distribution and the associated promotion certainly helps IMHO. It seems to me that the major struggle for smaller (particularly innovative) projects is getting community awareness, usage, and adoption...because without that it's hard to imagine them being considered successful (they can still be successful in the 'internal project' sense, but that isn't my notion of successful I guess).

Note this is also nearly always a struggle for large projects/companies as well, but they have the resources to throw $$ at that problem...and keep at it for the long term. So what I'm saying is that part of the value of the release train (or any distribution mechanism/release) is sharing those costs among several projects/orgs (i.e. the train) to the mutual benefit of all (more value created).

OK...I'm sure you'll all be disappointed ;-), but I'm finished with conversation as I've got to prepare to fly to Europe for some reason :). Hope to discuss this with some/many of you face to face there.

Scott