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
|