This page last changed on Feb 04, 2009 by jdeolive.


A proposal of a development process centered around a community managed road map.

Backwards Compatability

Proposed By

Justin Deoliveira

Assigned to Release



Under Discussion, In Progress, Completed, Rejected, Deferred


As more organizations get involved in GeoServer development it's become clear that more transparent planning of the project is needed. Multiple organizations are doing funded development on GeoServer, and effective planning to meet everyone's needs requires greater transparency.

To this end we seek to have an open process for establishing the roadmap, that everyone can plan against. The goal is to have there be no surprises in a release, that every potential feature is talked about before it comes in. This should also give the user community along with potential developers more insight in to what is being worked on, and should also allow us to get documentation in place before a release.

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


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.


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.


The Roadmap

The road map is a time line 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 and critical bug-fixes/improvements that will be implemented for that release.

The road map is structured into short term, medium term, and long term. The short term road map is made up of features scheduled for the next two releases. The medium term road map is made up of features scheduled for the remainder the current stable development branch. The long term road map consists of features scheduled against the next/unstable development branch.

Regular priority bugs do not show up on the road map per se. Bugs in general (assuming they are relatively minor) do not need any special process to be assigned to a release.

Implementing the Roadmap

Implementing the road map can be achieved with jira.

Short and Medium Term

For each jira release the following issues are pulled into the road map:

  • any "New Feature" issue
  • any "Bugs", "Improvements" with a priority of critical or blocker.
Long Term

For all releases the following issues are pulled into the road map:

  • any "New Feature" issue which has a critical or blocker priority

Current Roadmap

Using the criteria in the previous sections the current road map can be viewed here.

Maintaining the Roadmap

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 PSC. 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. Whether 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.

Updating the Roadmap

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


This section should contain feedback provided by PSC members who may have a problem with the proposal.

Backwards Compatibility

State here any backwards compatibility issues.


Andrea Aime: +1
Alessio Fabiani: +1
Justin Deoliveira: +1
[~jgarnett]: +1
[~roba]: +1


[JIRA Task|]
[Email Discussion|]
[Wiki Page|]

Document generated by Confluence on May 14, 2014 23:00