Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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:

  • Replace the static HTML quarterly status reports with an machine-processed XML file
  • Reduce each project's overhead of keeping this information up-to-date
  • Automatically remind project leaders when the information needs refreshing
  • Publish this information on auto-gen'd eclipse.org web pages. For example, the prototype master timeline has been useful - we can imagine other useful reports like that.

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:

  • DD/MM/YYYY - for a specific day
  • MM/YYYY - for a specific month
  • QN/YYYY - for a quarter

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

  • Summary, description, and leaders must exist.
  • Shipping must be non-empty unless releases has a release 1.0 that is not completed.
  • Releases must be non-empty but it is not required to have milestones.
  • Release-train is optional and should only be used if the project has opted-in to the release train and all the work that entails.
  • Third-party is currently optional.

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

  • At T-3 weeks, an email will be sent to each project leader reminding you to update your eclipse-project-status.xml file.
  • At T-2 weeks, if the file has not been modified, a second reminder will be sent.
  • At T-1 week, if the file has not been modified, a third reminder will be sent and it will be cc'd to the EMO.
  • At T-0 weeks, if the file has not been modified, two weeks worth of every other day reminders will be sent.
  • At T+2 weeks, a final email will be sent to the project leader and to the EMO saying something like "robo-emailer is giving up".

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.

Back to the top