Re: [eclipse.org-planning-council] T&P Feedback RE: Roadmap Process

[David M Williams <david_williams@xxxxxxxxxx>]

Don, 

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:	"'eclipse.org-planning-council'" <eclipse.org-planning-council@xxxxxxxxxxx>, <eclipse.org-project-leadership@xxxxxxxxxxx>, "'eclipse.org-requirements-council'" <eclipse.org-requirements-council@xxxxxxxxxxx>, <eclipse.org-architecture-council@xxxxxxxxxxx>
Date:	09/24/2008 05:21 PM
Subject:	[eclipse.org-planning-council] T&P Feedback RE: Roadmap Process

---

All,

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:

http://wiki.eclipse.org/RequirementsCouncilThemesAndPriorities

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-----
From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx]
On Behalf Of Bjorn
Freeman-Benson
Sent: July 25, 2008 3:58 PM
To: eclipse.org-project-leadership@xxxxxxxxxxx; eclipse.org-planning-council
Subject: [eclipse.org-planning-council] 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
     http://wiki.eclipse.org/Development_Resources/Project_Plan).
  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

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

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.

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

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.