GeoServer : Roadmap Process Draft
This page last changed on Dec 02, 2008 by jdeolive.
Outline of a project process centered around a detailed road map.
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:
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.
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 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:
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.
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:
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.
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.
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:
Proposed changes might include:
|Document generated by Confluence on May 14, 2014 23:00|