This page last changed on Dec 02, 2008 by jdeolive.

Outline of a project process centered around a detailed road map.

Motivation

Recently it has become evident that the GeoServer project process lacks transparency. Organizations that dominate the developer community have resorted to planning internally. This sort of anti open behavior has resulted due to lack of a good process and road map for the project.

This document is the draft of a process to ensure openness and transparency in project management. The primary requirements / benefits of this process being:

Transparency

The planning process is open and less subjective to the whims of those developers and organizations who are "more involved" in day to day operations of the project.

Planned Releases

Releases are time set, and unless unpredicted circumstances arise, will be respected. This gives everyone notice of releases and prevents the current process of surprising people with a release date via email to the list.

Balance

This process gives everyone an equal say about features, not only those who have funding. Those organizations wishing to sponsor features must go through the community. And the community always has a say and must approve such features.

Roadmap Structure

The road map is structured as a timeline of planned releases. Each release has a date attached to it and intervals between releases follow a regular schedule of around one month. Each release contains a list of features that will be implemented for that release.

As an example consider the current reversed engineered road map for 1.7.x:

1.7.0
  • Raster Symbolizer
  • Layer Level Security
  • MrSID,ECW,JP2K Support
1.7.1
  • KML Super Overlays
  • KML Extrude Support
  • KML Reflector Improvements
  • Layer Overview Page
1.7.2
  • GeoSearch
  • GeoWebCache Integration
  • Labelling Improvements

The items for each release should include new features, notable improvements and tasks, and major bug fixes. Minor bug fixes, regressions, and other minor issues need not be visible from the high level road map.

The road map should contain 4-5 future releases. This is not to imply that features assigned to those releases are set in stone.

Assigning Features

The process of adding new features to the road map is a process in which potential features are evaluated by the community and assigned to the release by the community. The prerequisites for adding features to the road map are:

  1. The feature has a sponsor. This means either a developer willing to carry out the work or a customer who is paying for it.
  2. The feature has has gone through the GSIP process if necessary. Wether a feature needs a GSIP can be decided by the PSC when the feature is proposed.

After a feature has met the above prerequisites it is assigned to a release on the road map. The determining factor for where a feature should fit into the road map should be time. Based on the estimate of time to implement the feature it is assigned to a release.

TODO: other criteria.

Bootstrap

There has to be an initial bootstrapping of the road map. This will involve members of the community who currently have planned features to collaborate and assign that work to up coming releases.

Maintainance

It is impossible to plan out a road map that will be static, things change so the road map must be dynamic and updated weekly. A sensible time to do the update is around the weekly IRC meeting. At each IRC meeting (and this includes meetings in all timezones) should review the road map and any proposed changes to it should be discussed. After proposed changes have been discusses they should be emailed to the developer list after the meeting. This gives those who can't attend the meeting or those who don't regularly attend the meetings a change to chime in. Given there are no issues with the proposed changes the road map is updated accordingly.

So to sum up:

  1. At weekly IRC the road map is presented as an agenda item
  2. Any proposed changes are discussed and a list of "candidate changes" is generated
  3. Candidate changes are emailed to the developer list
  4. IF no objections are brought forth the road map is updated

Proposed changes might include:

  • new features someone wishes to implement
  • features whose time estimate changes and must be assigned to a future release
  • features that present some other problems and must be re-evaluated (taken off the road map) or assigned to a future release
Document generated by Confluence on May 14, 2014 23:00