Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cross-project-issues-dev] plan best practices

Title: Re: [cross-project-issues-dev] plan best practices
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
is the equivalent of a "Theme" in the new plan.
    http://www.eclipse.org/projects/project-plan.php?projectid=dsdp.tm
The listed bugs are also elaborating finer details on the big picture, which
already is in the plan.
 
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
 
 


From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeff McAffer
Sent: Saturday, September 13, 2008 4:40 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] plan best practices

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

Back to the top