[
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
