No. That’s not it. If you plan to fail, you fail to plan. Nope. What was it my SCUBA diving instructor said? Oh yes… if you fail to plan you plan to fail.
Good planning is an important part of every Eclipse project. A project plan sets the direction of the project. It lets the committers know what sorts of things they should be working on. It lets the community know how and where they can add value with their contributions. It lets adopters know what to expect when they’re building products based on the technology produced by the project. In short, the project plan is a critical part of reaching out to and developing the community and eco-system around a project.
It is also the case that having a project is a requirement for all Eclipse projects. The Eclipse Development Process, section 5, has this to say:
The Project Leadership is expected to ensure that their Project Plans are consistent with the Roadmap, and that all plans, technical documents and reports are publicly available. To meet this requirement, each Project is required to create a transparently available Project Plan in an EMO-defined file format that meets the following criteria:
- Enumerates the areas of change in the frameworks and tools for each proposed Release
- Consistent with and categorized in terms of the themes and priorities of the Roadmap
- Identifies and accommodates cross-project dependencies
- Addresses requirements critical to the Ecosystem and/or the Membership at Large
- Advances the Project in functionality, quality, and performance
The EMO-defined file format, or “standard format” is defined on the wiki. There are numerous examples that you can draw from when creating your own project plan (Mylyn, RAP, IDE4EDU, and Web Tools are just some examples).
For a project plan to be considered “valid”, it will be in the standard format, be valid XML, conform to the schema, and contain future milestones. It’s not enough to have a plan that lists themes: to be valid, a project needs to have actual future dates so that committers, contributors, and adopters can adjust their own plans accordingly. The standard format schema has a specific place for dates (./release_milestones/milestone). It’s not enough to list dates in the HTML markup. One further requirement is that the plan has to be correctly captured in the project metadata on the Developer Portal; that is the “projectplanurl” field needs to point to the XML document (e.g. “http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_3_6.xml”).
At present, we have 17 projects with valid project plans. We have 40 projects with plans in the standard format but with missing milestones. A whopping 65 projects have plans that cannot be found (i.e. the plan URL is not specified in the project metadata), or are in an invalid format (be sure to check that the project plan document is valid XML). The good news is that the number of projects with valid project plans has been increasing steadily over the past few days. I’m encouraged by the willingness of project leaders to try and get this right.
In the past we’ve been a little negligent with respect to plans during reviews. Moving forward, the EMO pledges to help projects make sure that their plans are in place and valid as part of all release, graduation, move, promotion, continuation, or restructuring reviews. In fact, basically any kind of review, short of a creation or termination review needs to include a valid plan.
That said, it’s probably a good idea to have your project plan up-to-date at all times. If you need some help whipping your project plan into shape, let me know. Project leaders: you know how to find me.
