Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] T&P Feedback RE: Roadmap Process


you say "... further review by all councils ... " but what about individuals on one of the councils (such as me :) ? Would that be helpful? Is that what you meant? I fear if we "wait for a council" to get organized to give feedback, it won't get done quickly enough. So, don't mean to speak out of turn ... but I always have an opinion and will share it with little encouragement.

What form would you like this feedback in? Just notes here? Or, bugzilla? Talk page on the wiki? Or ... want me to just go re-write the darn thing, as I'd like to see it? [just kidding about that offer].

Here's some high level things to get started, but these are just high level comments on the whole document ... I'll refrain from getting too specific and wordy until you have a chance to answer the methodology questions above.

1. Let's can (remove) the Theme Categorization (the Active, Persistent, Deferred, and Pending). It's too abstract and doesn't help anything that I can see.

1.1 Deferred and Pending. are only relevant if we had an active group working on this document over time (and, then, only while working on it, but never appropriate for the roadmap itself, IMHO).

1.2 There's only three in the "persistent" category, and 15 in the "active" category (I think 15 ... hard to count, exactly) so let's just name the theme and skip the abstraction. By definition, most active ones should become persistent anyway, since they "haven't changed much in years".

2. There's a number of places in the document that say "... should ...". I don't think this document is meant to be prescriptive, but more descriptive, so nearly every case I saw of ".... should ..." could, or I must say 'should' :) ,  be changed to " ... could ...".  In other words, in most cases this document is suggesting things that could fit in to a theme ... not what projects should do with their time.

3. There's several (other) cases of a prescriptive tone where specific technologies are named. The most obvious (nearly rude) example of this is "Further Enhance P2".  I know you (or someone) meant well, but we really need to take the time to abstract out the "theme" of what's intended by that statement ... that is, describe what we, as Eclipse Foundation, really want to see. Then, whether P2 is involved or not is a whole other question, and up to each project to decide (mostly). For example, I'd word it something like the following (although this is partially already said in other themes):

"Ease of installation, deployment, of pre-canned packages (or products) while allowing easy discovery and mixing-in of additional functionality. This includes not only traditional Eclipse features and plugins but could also include the ability to pick from and install various runtimes, servers, libraries, or databases. I also could include not only the initial installation by one end-user, but could also include maintenance, remote installation or management of several installations, etc."

And, the name/tag for these theme would be "Provisioning".

I believe one litmus test of a true "theme" is if it is conceivable that each Eclipse project could contribute to that theme ... well, at least more than one or two projects. Otherwise, if it applies to just one or two, I think the "theme" is merely a requirement for that project (or two) ... and not a true theme. And, 1) I'm sure that Equinox already has the requirement to "Enhance P2" :)  And, 2) I'm pretty sure the Eclipse Foundation would never put specific requirements on specific projects! :)

A few other sections could benefit from a re-write with this idea in mind (namely, the sections on RCP, RIA, and perhaps embedded device software).

4. If we expect much review, we should fix it so the sections and paragraphs are all numbered, like an outline ... since otherwise it's hard to write down specific comments and give feedback on specific sections (given the primitive 'review' tools we have to work with :) [or, please educate me if there is some way to do it with the wiki.]

5. We should list, right in the headings, the key word (tag) people should use for the theme in their standard format planning documents. This not only will allow us to be consistent and meaningful in the "roll-up" plans (if there ever is one), but will also help signal, to me at least, what is intended to be the theme ... for example (an easy one),  is "multiple platform support" the theme, or is "vista" and "linux" the themes? Others are not so obvious to me.

6. One last playful dig ... where's the priorities in this "Themes and Priorities" document? :) Could it be renamed to say just "themes". It seems to me this document is evolving as a statement of "what Eclipse Projects normally do (in general)" and is simply a device to better absorb or think about the specific project plans. The priorities will pop out of each project's plan, I suspect.

Thank you for your efforts on this document and thank you for the opportunity to give feedback. I hope you (all) find it constructive and at least one or two of my points helpful.

From: "Donald Smith" <donald.smith@xxxxxxxxxxx>
To: "''" <>, <>, "''" <>, <>
Date: 09/24/2008 05:21 PM
Subject: [] T&P Feedback RE: Roadmap Process


As noted earlier this year, the new Project Plan format has tags for linking
to the 2008 Themes and Priorities.

To be blunt, not a lot of updates have been made to the T&P's due to lack of
response.  Only minor tweaks have been made over the last couple of years.
Based on limited feedback and my own personal experiences, I've made a quick
pass through of the T&P for inclusion in the 2008 Road Map:

Given this document serves as the basis of the T&P tag of the Project Plan
XML format, further review by all the councils would be very welcome.

- Don

-----Original Message-----
[] On Behalf Of Bjorn
Sent: July 25, 2008 3:58 PM
Subject: [] Roadmap Process

Project Leaders,

As project leaders, I'm sure you're aware that the Eclipse Board of
Directors requires us to put together a Roadmap each year. The process
and the deadlines that the Board has set for us are:

 1. By *September 30th, 2008*, all projects will have public project
    plans in the standardized project plan format (see
 2. The PMCs will review these plans during the month of October 2008.
 3. The PMCs will deliver these plans to the Planning Council at the
    end of October and the Planning Council will meet during the month
    of November (either physically or virtually) to write the planning
    section of the Roadmap.
 4. The Planning and Requirements Councils will deliver the complete
    Roadmap document to the Board of Directors at the end of November
    for the Board's consideration and approval during a plenary
    Council+Board meeting in December.

So, the key message here is that you (and I, because I'm a project lead
too, thus really "we") have to complete our project plans, in the
specified format, using the project meta-data and everything, by
September 30th. My calendar shows that we have 67 calendar days and 47
work-week-days (modulo various holidays) to complete our project plans.

- Bjorn

_______________________________________________ mailing list

IMPORTANT: Membership in this list is generated by processes internal to the
Eclipse Foundation.  To be permanently removed from this list, you must
contact emo@xxxxxxxxxxx to request removal.

_______________________________________________ mailing list

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

Back to the top