Hi Jeff,
many thanks for your comments about plannign best
practices. I thoroughly
believe that this discussion is the logical next step after
the initial discussions
about plan formatting (which produced a lot of disucssions
already, even
though projects were allowed to do the actual planning at
their disposal).
Best practices are the right way to go.
With respect to the DSDP-TM plans which you cited, in my
opinion each
Starting from this basic concept, a lot of your concerns
are less problematic:
-
Lost in hyperspace: The theme descriptions
are in the plan, no need to follow a link. The big picture is in the plan,
even without the links.
-
Change: The main plan directions don't
change. only the fine-grained individual work items
do.
-
Unexpected change by bug reporters: New bugs
always appear as "proposed" which makes sense even from non-committers
(they are allowed to propose). Committers change the milestone to "commit"
or "defer" a bug item.
I'm wondering why you find the TM 2.0 plan "more
effective" than the TM 3.0 plan, given that IMO they are equivalent while the
TM 3.0 plan gives more detail in addition to all
the high-level descriptions found in the 2.0 plan... in the fact, in TM 2.0
we've
been using explicit bugzilla dependencies from plan
items to work items, in order
to model exactly the queries which the XML plan now
gives us automatically. Now that did give us a "lost in hyperspace"
feeling at times...
I'm
not arguing that this is a best practice, but at least I've come to
appreciating the plan as an excellent working instrument for myself... and do
hope that the
community finds it useful too, so I'm really happy
about your comments and
would
appreciate working wore with all of you on further
improvements.
Regarding the "hard to create XML / lost in
prefixes" issue, that's mostly because
I'm a
total XML dummy myself and had to figure things out first. From what I
know
today,
I'd propose a scheme as used by the MTJ
project, which simply prefixes all
plan
tags with a p: -- easy to remember, easy to write, easy to look
up.
But I
appreciate any reader of the Wiki page to simplify it, feel free to get rid
of
the
overly complex detailed stuff that I've put there...
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
Yeah, this is an active topic of discussion on the PMC. We
will have that sorted out soon.
As for discussing the plan process etc,
it would be good to have that topic on the agenda for the face to face (its
not obvious that it is on the current agenda) but the end of Oct will be
somewhat late for the current cycle.
For the most part projects should
produce plans much like they have previously wrt content, durability, level,
... The introduction of a standard plan document was not intended to
change that per se. For example contrast these two plans for the same
project http://www.eclipse.org/dsdp/tm/development/tm_project_plan_2_0.html
http://www.eclipse.org/projects/project-plan.php?projectid=dsdp.tm The
first one is IMHO more effective as a community facing plan document.
DSDP folks, I am not picking on you, you are benefiting from being pioneers
and forging a path through the planning jungle :-) That and I could not
find an old plan for Dash...
Another point to mention is that one of
the main drivers for the plan standardization was to help in the creation of
the roadmap. With super fine-grained plans the creation of the road map
will be quite challenging.
Just to clarify, I am all in favor of
fine-grained, reality reflecting documents etc. We produce milestone
plans for this purpose. The project/release plan however should be
something more considered.
Jeff
Richard Gronback wrote:
Jeff, who represents the Eclipse RT PMC on the
Planning Council? I just realized nobody is listed here: http://www.eclipse.org/org/foundation/council.php#planning
Thanks, Rich
On
9/13/08 8:02 AM, "Richard Gronback" <richard.gronback@xxxxxxxxxxx>
wrote:
These are some of what I expect are many questions
to come regarding the plan, which I believe should be fleshed out by the
Planning Council (as incredible as that may seem). It is still
surprising to me that the development of the plan format and its
expectations has gotten to this point without direct involvement/ownership
by the Planning Council.
As such, we have an agenda item to discuss
the plan for the plan and its delivery to the Board/Community during our
next in person meeting, so I’d encourage these and other questions be
listed there so that we can prepare for a quality discussion.
http://wiki.eclipse.org/Planning_Council/Oct_27_2008
Thanks, Rich
On
9/13/08 1:21 AM, "Jeff McAffer" <jeff@xxxxxxxxx> wrote:
First, thanks to everyone who has contributed to
the standard plan format effort. This has been a great example of
the community coming together to achieve a common goal for the good of
everyone. I read through http://wiki.eclipse.org/Development_Resources/Project_Plan some
of the plans already available, and the various related bug reports in
particular https://bugs.eclipse.org/bugs/show_bug.cgi?id=215301 A
few questions came up while putting together the Equinox
plan...
- What is the intended use/audience of these
plans? In my projects we have always attempted to address the
consuming community and attempted to paint a general picture of the
kinds of significant new directions, functions, etc that are on the
table for the next release. In looking over the DSDP and DASH
plans I was struck by how detailed they are. There are a great
many items (bug reports) listed. Given the volume and the format (many
entries starting with the same [tag]), the document is not very
consumable IMHO. People can find out what is going to be worked on
in any given milestone by doing a query but that is raw information, not
a considered and crafted plan.
- What should the community
expectations be wrt the plans changing? Our plans have always
changed say 4 times as the dev cycle goes on. This IMHO a positive
attribute as it more accurately reflects reality as reality unfolds.
However, where the plan is composed of bug queries for particular
[tag]s (or the like) there appears to be a danger of anyone in the
community unknowingly putting something on the public plan simply by
putting [tag] in the summary line. Change is good but too much
churn and fluidity undermines confidence.
- To address the above
two concerns I propose that we explicitly state a best practice for
project teams to use the "plan" keyword (or any other explicit and
relatively exclusive marking mechanism) to clearly and explictly mark
bug reports as being for the plan. Following this approach we
would likely end up with fewer plan items and less churn. Both changes
would increase the consumability of and confidence in the project
plans.
- What do we think plan readers want to see and should
expect? I saw some discussion about having more text related to the
plan items in the plan itself but no real conclusion. Currently
the rendering shows only the summary (I suppose that is a conclusion
:-). Again, from a consumability point of view this is less than
optimal. It requires a lot of clicking and makes it hard to see
the big picture. I've been to countless meetings where people sit down
with a printed copy of the plan and talk about the different items.
If all the real content is had only by following a link, ... In
part this is a rendering question but from a best practice point of
view, what do we think plan readers want to see and should expect?
If you walk up to a project about which you know little, what do
you expect from their plan document? I expect to see some sort of
digested form of the raw information that tells me the intent,
direction, challenges and what problem is being addressed. Imagine
trying to get funding based only on your plan document. Again, we can
have links to all the gory details. Make the simple thing simple
and the hard things possible...
- Should it be easy or hard to
create a plan document? (sucker question) The main plan wiki page
http://wiki.eclipse.org/Development_Resources/Project_Plan
highlights a plan template designed for "little HTML" and implies
that the "lost of HTML" approach is for legacy folks. From a best
practice point of view, should plan authors be producing rich plans or
machine generated queries? I guess my point here is that while
people are free to choose which xml tagging scheme they use, we should
be encouraging them to create good looking, easy to read plans.
Guiding them towards archane XML namespace markup and "prefix"ing
is likely to make crafting such a plan appear unattractively hard.
I suggest that we reorient the main plan page to guide folks
through the simple path first with off-shoots for the non-XML-averse
folks.
Again, I very much like the path we are on.
These comments/questions are intended to expose and refine the
plan crafting best practices with the end goal being more consumable and
informative plans that are produced more easily.
Jeff
_______________________________________________ cross-project-issues-dev
mailing list cross-project-issues-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|