Revision as of 17:05, 19 February 2013

Project management functionality is being migrated from Eclipse Developer Portal into the Project Management Infrastructure. This document (and linked document) are works-in-progress.

In 2011, the Eclipse Foundation began a new effort to replace the existing project management infrastructure--which includes the Developer Portal--with a new unified infrastructure with the intent to make project management activities more consistent and generally easier for all involved.

Themes of this effort include:

• Improved consistency. Configuration/data-driven project web presence, direct linkage between releases, reviews, and plans. Information--including basic project metadata, project plans, and release review information--is captured and retained in a consistent (and easily leveraged) data-based format (rather than in multiple documents in arbitrary formats).
• All-in-one-place. Committers are able to edit information in place on the project information pages. Text/information in one place with links in another is eliminated where possible. Comments and discussion related to reviews, elections, etc. are connected directly to the item being discussed.
• Get started faster. By default, projects are provided with a data-driven website that includes consistent links to project releases, reviews, downloads, etc. Projects can opt to override the default and provide their own customized web presence.Setting up a project presence is a matter of configuration, not PHP programming against proprietary APIs.

Links

• Development
• Technology Choices
• Project Management Infrastructure/Overview and Design
• Live instance for testing and experimentation

Overview

The following themes guide the Project Management Infrastructure:

• Trust committers to do the right thing;
• Once and only once (avoid repeating information);
• Everything is undoable (i.e. revision tracking); and
• Do the simplest thing that can possibly work (avoid complexity)

We assume that committers will always endeavour to do the right thing. Specifically, we give committers leeway to do what they think is right. This, in combination with revision tracking means that mistakes can be easily undone. A committer may, for example, make ill-informed changes to a project's scope that is later reversed by the project lead or PMC.

It would be easy to get mired in multiple layers of approvals for various activities, or complex logic to prevent committers from shooting themselves in the proverbial foot. But such complexity makes the cost of later change and ongoing maintenance prohibitively high.

Note that we make a distinction between committers and general users. We do not--as a general rule--trust the general population to do the right thing. For completeness, we include with the definition of "committers" all those users with roles that permit them access to the project (including project leads, pmc members, EMO staff, etc.)

Projects

Project information pages, which are are used as the primary website by many Eclipse projects, are generated from data provided by project committers. On these pages, you will find useful information such as project description, scope, Bugzilla summaries, commit summaries, lists of repositories, and a multitude of useful links.

All of this information is presented for consumption by the general community.

Users are not required to log in to access information about projects, releases, and many other aspects of the system. But if the user does log in, more options are made available to them.

A logged in user, for example, has the ability to edit information about projects for which they are a member. That is, a project committer, or project lead can edit information about their projects. In this case, an "Edit" option appears.

Clicking "Edit" puts the system into "edit" mode allowing the user to make changes.

All changes are tracked via a built-in revision control system. Other project members can review revisions to see who changed what and when; more usefully, the information can be reverted if mistakes are made.

Note that PMC members and EMO staff members can also make changes to project information (these changes are also tracked).

Releases

At the beginning of a release cycle, projects are required to describe their plans for the release in a project plan. A project plan is expected to evolve somewhat during development on the release. At the end of the release, a project is required to provide retrospective documentation of the release for community review. All of this information is captured and maintained by the Project Management Infrastructure.

The primary benefits of maintaining this information within the system are consistency in how the data is provided, and ease of dissemination. This information is useful and valuable: having it in a format that is easily consumable will mean that it can easily be disseminated to a wide audience.

The "edit" mode for a release provides the ability to set the date and name of the release. Additionally, there are several tab groups of fields to specify a description, project plan items, and review items.

There other benefits of this set up:

• Finding and updating this information is consistent and easy; and
• By having explicit fields with built-in help text, the committer/project lead providing this data knows exactly what data is required and in what format.

Again, it is assumed that project members will revisit and tweak this information periodically during the development cycle of a release.