If you plan to plan, you fail to fail

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:

  1. Enumerates the areas of change in the frameworks and tools for each proposed Release
  2. Consistent with and categorized in terms of the themes and priorities of the Roadmap
  3. Identifies and accommodates cross-project dependencies
  4. Addresses requirements critical to the Ecosystem and/or the Membership at Large
  5. 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.

This entry was posted in Community. Bookmark the permalink.

4 Responses to If you plan to plan, you fail to fail

  1. Chris Aniszczyk says:

    Wayne, I think this would be useful to send out to the cross-projects list also.

  2. Scott Lewis says:

    Hi Wayne,

    While I think that having and requiring project plans is in general a good thing, I’d like to point out that when almost all projects are increasingly struggling WRT resources (i.e. people to do the actual work), increasing the process requirements will make many projects less able to be innovative.

    Given that EF projects already have a bit of problem with innovation (whether due to resource constraints or not) continuously increasing process requirements doesn’t help with that…and in my view lack of innovation amounts to a bigger strategic problem for the org.

  3. Wayne Beaton says:

    Hi Scott. Thanks for your comments. FWIW, this is not an increase in process requirements. This is an existing requirement. Having said that, I am very much against having more process than is necessary. I understand that resourcing is a problem. It is my opinion, however, that having a plan is one of those things that makes it easier for people to contribute. As I said in the original post, the plan lets contributors know where they can contribute; where they can add value. So, while this is indeed process that distracts from the business of writing code, the theory at least is that it will ultimately help your project find new blood and increase the potential for innovation. I don’t believe that there can be innovation without communication.

    I have been careful all along to make sure that everyone is aware that I am very willing to help projects assemble their plans and put them in place. I am very willing to help reduce the burden of process. Getting me to help has the added benefit of arming me to be a better evangelist for your project.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s