[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[eclipse.org-planning-council] Proposed Eclipse Project reporting infrastructure
Planning Council members,
At the Council meetings a few weeks ago, I agreed to propose an XML file format and some tools for reducing the overhead of reporting your project's status while increasing the utility of the status information for other project leaders and other Eclipse members. Here is my first draft proposal - please comment and critique. Thank you.
--
*Bjorn Freeman-Benson*
Technical Director, Open Source Process and Infrastructure <http://eclipse-projects.blogspot.com/>
Eclipse Foundation <http://www.eclipse.org/>
voice: 971-327-7323 (PDT, UTC-7 <http://www.timeanddate.com/worldclock/custom.html?cities=202,188,195>)
email: bjorn.freeman-benson@xxxxxxxxxxx <mailto:bjorn.freeman-benson@xxxxxxxxxxx>

Title: Eclipse Planning Council Minutes

Proposed Mostly-Automated Planning Reporting System

June 6, 2005 - Bjorn Freeman-Benson

Goals

At the May 2005 Planning Council meeting, we decided that Bjorn would put together a mostly-automated planning and reporting system for Eclipse projects. The goals:

File Format

Each project will have an eclipse-project-status.xml file in its root web directory.

<project
  name="project_name"
  url="" url..." />
  <summary>...executive summary of current status...</summary>
  <description>...description of project...</description>
  <leaders>
    <leader email="name1@xxxxxxxxxxx">first1 last1 optional_description1</leader>
    <leader email="name2@xxxxxxxxxxx">first2 last2 optional_description2</leader>
    ...
  </leaders>
  <shipping>
    <release url=""
    ...
  </shipping>
  <releases>
    <milestone date="date" 
               url="" 
               status="completed|scheduled|tentative">name</milestone>
    ...
    <release date="date" 
             url="" 
             status="completed|scheduled|tentative">name</release>
    ...
  </releases>
  <release-train>
    <head>...version/build that works with the HEAD of the release train...</head>
    <major train-version="...">...version/build that works with this major train release...</major>
    ...
  </release-train>
  <third-party>
    <item>...description of library or code...</item>
    ...
  </third-party>
</project>

Dates

The date can be any of these levels of precision:

You won't be allowed to be more specific than a day nor vaguer than a quarter.

Future Labor Saving Features

In the future we'd like to be able to gather the project description, shipping releases, and third-party inclusions automatically from the website, the downloads, and the feature.xml files. For now, however, it will need to be redundantly entered here.

Reports

I envision four initial reports from this data.

  1. Release Timeline. Like the prototype master timeline. The master timeline will not include Technology projects (or, in the future, Research projects) on the theory that Technology projects are not "major Eclipse projects".

  2. Milestone Timeline. Same thing, but showing all the milestones as well. It will be big and probably fairly cluttered.

  3. Quick Reference. A one-page per project summary of all the projects. Useful for printing and flipping through on an airplane trip.

  4. Validity. A report showing the "up-to-dateness" status of each project's eclipse-project-status.xml file. Green for up-to-date. Yellow for up to 30 days out of date. Red for 30-90 days out of date. Red with underlines and bold for more than 90 days out of date. Black "MISSING" if the file does not exist.

Updating

This file should be updated with current information each quarter. Current will be:

  1. modified within the last three weeks of the quarter
  2. has an executive summary that is different than last quarter's summary
  3. has all the required sections and proper formatting of dates, etc.

There will be an automated reminder email. The email will include why the automated program is sending you this email, e.g., "hasn't been updated" or "date field '27-Jan-2006' is not in DD/MM/YYYY or MM/YYYY or QN/YYYY date format".

Implementation Schedule

Review, comment, and critique during June 2005.
Release timeline converted to use new XML format and old .dates.txt format by end of July 2005.
Reminders implemented by end of August 2005.
Remaining reports implemented by end of September 2005.

The goal is to switch to this reporting system before (or at) the next Council meetings in August, and to have the entire system working before we have to generate the next Roadmap at the end of 2005.