Successfully requesting and integrating new features and improvements in GeoServer
Clone this wiki locally
This page assumes you want to ask for a new feature, or an improvement, against GeoServer (or GeoTools) and describes what expectations you should have, and how to proceed for its succesful integration into the code base.
Asking for a new feature/improvement
When considering a new feature or an improvement to an existing functionality there are two critical items to consider:
- Making sure the request is accepted by the community in terms of the functionality it provides, its interaction with the existing functional bits, the eventual protocol/GUI developments, and internal development
- Putting enough developer resources behind the idea to make it happen
The first item is normally achieved by open discussion: get on the users list and discuss the new functionality, providing as much context as possible, and be open to others chiming in and providing improvements, perspectives on how it interacts with the other bits, and so on.
Finding development resources is really up to you and the other people interested in the feature/improvement. Just sharing an idea, hoping that someone will implement it, in their spare time, within any useful deadline for your consumption, is normally a recipe for failure: the ticket tracker is full of such requests that are several years old. In fact, we want to discourage people to just opening "feature request" and "improvement" tickets unless they have successfully discussed and resourced the idea beforehand.
The two simple forms of resources are your own time, or money.
If you have developer skills and want to contribute to the project directly, you can just do the coding yourself (following the contribution rules, see below), make a pull request, follow up with the reviews and get it merged. It's normally a good idea to ask directions, while you cannot demand it, core developers are normally happy to give you some pointers to the classes/code areas that will need to be modified, and discussing a bit your implementation plans in advance might avoid unpleasant surprises when the pull request is done.
If instead you have no developer skills but can fund the new feature on your own, you can just go directly to the commercial support providers and ask for a quote: in case of successful negotiation they can help you develop the idea, socialize it in the community, and get it implemented for a fixed deadline.
In case you cannot develop nor fully fund the change yourself, it's still a good idea to discuss the feature in public: you might discover the same result can be achieved by simpler/existing means, by a easier to code/fund modification, or try to rally other users to fund the development together.
Depending on the size and type of contribution different levels of discussion might be needed.
For small improvements and isolated new features you can normally just get away with a mailing list discussion, making sure people are happy with the direction things are going, and in particular, in case of changes to a single module, it's important to make sure the module maintainer is ok with it.
A feature could be its own plugin module, in that case you can just ask to create such module and code your way in without much red tape (you will be the maintainer of said module).
For large changes involving core modules, and anything that has backwards compatibility implications, a formal proposal will need to be written, discussed, and finally voted by the Project Steering Committee
In case you are coding the new feature/improvement make sure you are following the coding guidelines, testing, and contribution agreement requirements as detailed in the contribution guide. In case of doubt, hop on the developer list and ask for directions.