Planning Council/Oct 27 2008

Meeting Title:	Planning Council In-Person Meeting @ EclipseWorld 2008
Date & Time:	Monday Oct 27, 2008 from 8:00 am to 5:00 pm Google calendar event
Place:	Hyatt Regency Reston

Attendees

• Richard Gronback
• David Williams
• Pat Huff
• Anthony Hunter
• Markus Knauer
• Oliver E Cole
• Bjorn Freeman-Benson
• Neil Hauge

Regrets

• Oisin Hurley
• John Duimovich
• Karsten Schmidt
• Doug Gaff

Topics

• Galileo Requirements for Participation - Finalize list
  • The list was refined and agreed upon. Each will be added to Bugzilla under the new Eclipse Foundation > Simultaneous Release > Galileo component with the appropriate priority (P1 = must-do, P2 = should-do) and target milestone. A clone of each bug will be created for each participating project with a dependency on the master bug to allow for reporting.
• Discuss project plan format, content, and ownership (see details below)
  • The consensus was to leave the Galileo plan as a high-level document with rollup in the form of links to participating Galileo project plans, and include bugzilla queries for the entries listed above. Bjorn's report for non-Galileo projects need to be addressed by individual PMCs to ensure each project provides a plan, as the Planning Council also agreed this is an acceptable requirement for each project for any release or continuation review.
• Create planning section of the Roadmap to present to the Board at December meeting, using input from individual Project Plans per this.
  • As mentioned above, the plan will be provided in the form of the now-standard plan.xml format with Galileo participation requirement Bugzilla queries to track progress.
• Plan status per project. Should plans be required by M3 as a train must-do?
  • Added as a requirement, though M4 was agreed as the timeframe.
• Galileo participation status
  • Each project should declare intent with Planning Council representatives so that each can have its tracking Bugzillas created and be added to the overall project plan. Each project or PMC to decide on what level of granularity they'd like to have presented on the rollup plan.
• Galileo deliverables (EPP packages, update site, all-in-one, etc.)
  • It was agreed that the product-based build proposed be used as the basis, which provides p2 metadata and content repositories and unified artifact location for all participants. The actual product produced will not be provided as a downloadable to all, though certain requests may be satisfied on a case-by-case basis.
  • EPP packages will be provided, though likely based on .product files as well.
  • The installer (RAP-based p2 director) will be promoted, with categories to be aligned with those presented in the main Galileo repository. This requires that only Galileo train participants are allowed to be made available in this custom installer. The initial proposed structure of categories is found below, with an additional SDK site/categorization to also be provided.
• Email from Babel team re: gray box testing of strings
  • It was decided that the testing will be a should-do item, though Babel participation is a must-do for train projects.
• PC update to members on Nov. 17th before ESE (wwdi?)
  • Bjorn agreed to provide the update with material provided by Rich
• PC meeting 12/10, the day before the plenary in San Francisco... needed?
  • It was agreed that an in-person meeting in December would not be required, as it's unlikely we'll need more than calls in the near future, and also as a consequence of tightening travel budgets
• TPTP "POG" initiative
  • Advised TPTP broadcast to committer list their request for participation on helping to improve the profiler, and to perhaps consider those open bugs that have the performance keyword for potential contributors.
• SDK composition
  • It was agreed that some guidelines be provided to bring consistency in the way each project packages SDKs are necessary. To being, a basic wiki page with a list of the current issues and recommendations for a solution to begin the discussion. Once a consensus is reached, an approach to providing an SDK site to complement the end-user tooling site for Galileo consumption can move forward.

Project Plan Discussion

From Jeff's email:

• 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 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.

• These issues/questions were discussed in general, with no obvious problems identified. We're going to deliver a basic plan (see above) until suggestions for improvement are presented by consumers.

Galileo Categories

Some discussion on improving/simplifying the category list for Galileo resulted in the following proposed structure. A separate SDK structure will be provided as well. Note that elements not found within categories are either expected to appear in the default uncategorized category, or be found using the filter on the dialog. Also, changing the view to by-name or by-site may facilitate finding additional features. Sections are used to indicate the web-based UI division of categories.

Note that this is a basic outline and still needs to be refined/completed.

Wizard page #1

• Programming Languages
  • Java
  • C/C++
  • JavaScript
  • Ruby, etc.
• Web Development
  • HTML/CSS/XML
  • JavaScript
  • JavaEE
  • RAP
  • STP elements

Wizard page #2

• Database Development
  • DTP elements
• Modeling
  • UML
  • DSL Toolkit
  • BPMN
  • SCA
  • etc.
• Testing and Performance
  • Profiling
  • etc.
• Device Development
  • DSDP elements

Wizard page #3

• Collaboration
  • ECF
  • Mylyn
  • CVS
  • SVN
• Tools & Goodies
  • Buckminster
  • Remote Access
  • UDC
  • BIRT
  • Runtime elements

Other Discussion Items

• Regarding the naming of subsequent release trains, it was proposed and accepted that the PC provide a short list of names to be decided in some manner during EclipseCon. The only concern is that the naming process should not serve as too much of a distraction from the release in progress. The current short list includes: Io and Triton
• It was suggested that a ramp-down policy element be added to the current plan format
• The consumption of Orbit bundles was discussed, as although many projects utilize bundles, they often do it in different ways (e.g. with dedicated feature, with 3rd party feature, with no feature). An approach should be recommended and added to future release train participation requirements.
• On the discussion of a single all-in-one Galileo download, the bandwidth issue was raised and led to the recommendation that perhaps eclipse.org servers should limit download access by allowing only "Friends of Eclipse" access, leaving mirrors to service the majority of the community.

Action Items

• Create bugzillas for use in plan administration (Bjorn)
• Invite Babel project to next PC call to discuss project status and perhaps demonstrate UI testing procedure (Rich)
• Provide PC update material for presentation at members meeting prior to ESE (Rich)
• Create a wiki to begin discussion on SDK composition and delivery (Rich) SDK Composition
• Organize a mechanism to vote on train name during EclipseCon, selected from PC-provided short list (Bjorn)
• Remove galileo flag queries from the current plan.xml for Galileo (Rich)
• Send list of projects as desired to be listed on Galileo for linking to individual plans (which may then link to plans), or better yet, apply patch to plan.xml found on this bug (All)

Additional Topics

• IP process improvement discussion with Janet Campbell - ?

Reminders

• December 10-11, 2008 - plenary session with Board

Action Items

• TBD