This page assumes you want to ask for a bug fix, improvement or new feature in GeoServer (or GeoTools), describes what expectations you should have, and how to proceed for its successful integration into the code base.

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

Bug fixing-wise, normally only the second item applies, even though sometimes what looks like a bug some is an intended feature for others, so a bit of discussion never hurts.

That said, let's have a look at the two necessary steps, discussion, and resourcing.

Get on the GeoServer mailing lists and discuss the change, 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.

Which mailing list works best depends on your background:

• If you are a developer and will implement the change, probably go directly to the geoserver-devel list
• If you are not going to develop the change yourself, best to stick on the geoserver-users mailing list instead

Finding development resources is up to you and the other people interested in the fix/improvement/feature. Sharing an idea or a problem, hoping that someone will implement/solve it, in their spare time, within any useful deadline for your consumption, is often a recipe for failure.

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. These tickets are also systematically closed after one year of inactivity. Bug reports are instead welcomed and are kept indefinitely in the issue tracker, just be aware that there is no expected deadline to get a fix for them, once reported.

The two main forms of "resources" are your own time, and 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 for directions: while you cannot demand it, core developers are often happy to give you pointers to the classes that will need to be modified. Discussing a bit your implementation plans in advance might avoid surprises during pull request review.

If instead you have no developer skills but can fund the new feature on your own, you can 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 an 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 fixes, 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 a module and code your way in without much red tape (you will be the maintainer of that module).

For large changes involving core modules, and anything that has backward 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.