Opps, forgot one suggestion ... 5. could
we add an optional "help wanted" attribute to items? We could
both list these in some
verbose versions of milestone plan and
would provide a way to "pick out" items for special display on
"help wanted community pages" where we think
some item would be needed/useful, but
for which we know of know one able/willing to work in it. (We have one,
example, "Content Assist for DTD's"
that would seem appropriate to list as such an item).
----- Forwarded by David
M Williams/Raleigh/IBM on 01/11/2005 03:10 AM -----
David M Williams/Raleigh/IBM
01/11/2005 03:09 AM
Re: [wtp-committers] XML
based milestone plansLink
Very cool ... now if we just had a web
app to update and maintain the lists :)
I do have a few comments and suggestions:
Why are we still using wtp-committers@xxxxxxxxxxxxx list? I don't
think we need it now that we have
improved eclipse infrastructure support
and better defined voting processes -- no offense to object web and
many thanks for helping us get started!,
but I believe anything on this list can and should go on wtp-dev list.
(If there's no objections, or reasons
I'm missing, perhaps Naci could have other list "turned off"
to sender with appropriate message?).
More to your point,
I think it'd be nice if "low", "medium", "high"
was also "printed out" on web rendered version
in brackets immediately before item?
I'm not sure of the relation of "top items" and the rest of list
.... shouldn't the top items be only "high" priority
we consider "stop ship" if not met for milestone? (In that case,
is there a way they can be automatically
out" of whole list and put in the "top" section?). Even
if have to be manually duplicated, I think that
be the objective of that section, right?).
4. In the item element, I'd suggest a "detail"
tag as well as a "description" tag. The description would be
out" for most high level project wide plan displays, but the 'detail'
could be ignored, but via
URL, or what ever, developers and co-developers focused on one particular
see the detail if they'd prefer. That way, there's a clear "short"
version that gives gist of item and a
"long" version of the item (when desired) that gives more details
some developers might need
know. For example (only),
Document Designs, API, and JUnit tests
During M3 we'll focus primarily on core (model)
Designs and APIs.
We'll detail not only "standard"
DOM APIs we support, but also, the
extensions to that API, related to Adapters
and ReadOnly APIs.
But don't let these minor comments detract
from the fact that I think this *is* very cool, and *very*
helpful to having better milestone plans.
Thanks very much,
Craig Salter <csalter@xxxxxxxxxx>
01/10/2005 11:51 PM
[wtp-committers] XML based
I've checked in some XML based milestone plans (well ... preliminary plans)
and related stylesheets into the WTP website. Here's a description
of how they work, how you can use this for your own simple milestone plans,
and some more advanced milestone planning stuff you can do if you're keen.
Let me know if you have any comments or suggestions.
Component Milestone Plan Document
Here's a link to a simple milestone
plan for the xsd component
. It was designed to resemble a typical eclipse milestone
document (e.g. the jdt
ui milestone plan ). By
virtue of an XSL style sheet the file appears in a web browser as though
it's a pretty HTML document, but in fact it's just a simple XML file (use
'View Source' in your browser and see for yourself). Here's
a simplified overview of how the plan document is structured (note that
Schema for a milestone plan
 is provided).
milestone <-- one or more
... usually a 'current' plan and a preliminary plan for the next milestone)
category <-- work items are
categorized according to function (e.g. 'Quick Fix & Quick Assists')
item <-- straight
forward items can be described as a single bullet
item <-- more
complex work items can be broken down into multiple 'teps, which appear
as 'sub bullets'
Combined Overview Documents
Once the milestone plans are in XML format its easy to write additional
reports that can query across multiple component plans to create summary
documents. For example, here's a Milestone
Overview document 
that queries all of the component plans (well for now there's just a couple)
to produce a list of noteable items. Note that in order to make items
show up in the overview just specify a 'priority' attribute on the <item>
element in the mile stone plan xml file. In this way we're specifying
that the item should be called out in the overview document (BTW I find
the 'Top Items' listed in a component milestone plan are a good fit for
'notable' items in a combined overview)..
Milestone Schedule Calendar Reports
Optionally, component milestone plans can be 'annotated' with additional
scheduling or planning information. For example work items can be
assigned to developers and sizing information can be added. Here's
an example of a work item that's been annotated with additional scheduling
<!-- here's a work item without any 'scheduling
XML Schema refactoring support</description>
renaming - update references to renamed
<!-- here's the same work item with added
'scheduling info' -->
the 'developer' element
specifies the owner of the -->
the 'start' attribute
specifies the milestone week when work should begin -->
the 'length' attribute
specifies the milestone week when work should end -->
the 'pds' attribute
estimates the 'person days' of work required to complete this work -->
XML Schema refactoring support</description>
start="2" length="1" pds="2">
renaming - update references to renamed component</description>
Given this extra information we can generate a calendar
report for a group of developers
. Notice that value in brackets to the right of each developer's
name specifies the number of person days of work that have been allocated
to the developer. I find this calendar view handy when planning
work to make sure that developers are allocated work evenly and according
to their available time. It also looks good hanging on the
wall beside your monitor :-) Finally I should point out that its
easy for other groups to customize this calendar report for their own components
and developers by modifying the 'report' xml file.