User list posting guidelines

Regardless of whether you are just starting out with GeoServer or have been using it for years, we encourage you to subscribe to the user list and take an active part in the community. To help make the user list as useful and friendly as possible we ask you to observe the following code of conduct.

The user list is not the right place to discuss details of security issues

If you encounter a security vulnerability in GeoServer please take care to report the issue in a responsible fashion. Do not use the mailing list, go intead to the Jira bug tracker instead and follow the "Responsible disclosure" instructions there.

Take a little, give a little

The user list is there to help you but it works best if you help it too. Give back to the GeoServer project and community by answering questions, or pointing people towards other useful sources of information when you can: we will like you a lot. If we notice you ask questions without ever helping other people, we'll be less inclined to help you in return instead (but don't panic, if you don't care about participating commercial support providers can handle your needs).

Start discussions on the mailing list, keep it on the mailing list

You might be tempted to contact some of the people trying to help on the mailing list privately: please refrain from doing so, on the mailing list more people can look at your message and provide answers, share different points of views, and besides that, messages on the public mailing list are archived for future reference.
If someone answers your requests please make sure your replies keep on being sent to the mailing list for the benefit of the entire community.
However, it's fine to send private messages if you are trying to share sensitive information which is necessary to solve the issue, or if you are trying to engage a developer in a commercial development /support contract.

Be polite

Messages to the user list are not moderated so whatever is in your post when you hit the send button will be seen by all. Attempts to get undue attention, such as marking the message as "urgent" or title it "help me!!!", use a subject in full capitals, or sending multiple times the message because you did not get an answer right away likely result in your message be ignored.

GeoServer activities follow the Contributor Covenant Code of Conduct as part of the Open Source Geospatial Foundation commitment to diversity.

Check first, the answer might already be out there

Before posting a question, check to see if it is already answered in the following:

  • User Guide
  • User list archives
  • Use a web search engine with the error message you're getting, or with keywords summarizing the problem you're experiencing. Sometimes the solution is already available in a blog post, and other times or the search engine will get you straight the the documentation page talking about the problem.

Post enough (but not too much)

If your are experiencing a problem when configuring data, making REST calls or using the OGC services it normally helps to have a certain amount of information from the start.
You can try to make a quick question before gathering all this data. We understand the list is long, but knowing from the start that you're on Linux using shapefiles vs Windows using SQL server, or using GeoServer 2.0.2 vs a nightly from trunk makes a world of difference in the answer you can get.
The list of information you should provide is:

  • Your GeoServer version, Java version, and operating system (e.g., GeoServer 2.4.2 running on Java 1.7.0_54 64 bits, running on Windows 7)
  • The full stack trace of the errors you get, if applicable (look for it in the GeoServer logs, or enable "verbose exception reporting" in the "server" panel to get it also in OGC error reports)
  • If you're publishing data fetching it from another software, the name and version of other software GeoServer is interacting with (e.g., PostgreSQL/Postgis, Oracle and so on)

Avoiding to post "too much" is also important. Please realize the user list works off volounteers answering in their spare time or on a work pause. This means they will have little time to read your mail, figure out an answer, and write it down. Try to keep the mail short and on point, if you have multiple questions it's best to split them among separate mails, focusing on one problem (and thus one answer) at a time. In short, try to make it easy and most importantly quick to help you.

Mind that attachment

We love to get screenshots and sample data from you, but the maximum size of a message posted to the list is 200KB. If you need to share larger files, you should upload them to some server and then link to them. Some popular free choices for doing that are Google Drive (share with anybody that has the link) or Dropbox (put the file in your public folder and share the link to it).

Be patient

Remember questions are answered by volunteers, often in their own spare time.
Depending on the work and life schedules of the GeoServer developers and other useful list members, it might not be possible to respond to your question immediately or even at all. It could also be that no one on the list knows the answer.
If your project requires immediate, guaranteed assistance you should investigate the commercial support options available for GeoServer

Share your solutions

If you have posted to the list seeking an answer to a GeoServer problem, and then discover the solution yourself, please take the time to share it with the list: your answer will remain in the archives for the benefit of other users.
Also, if an answer solved your problem please let us know that, it will help morale of whoever helped you

If it turns out it's a bug

First off, check the bug tracker and if there is no existing report of that problem, create one and provide information on how to reproduce on a developer machine:

  • a data sample (no need to provide it if you can reproduce the issue with the demo data coming with the geoserver installation)
  • the style, if applicable
  • the OGC/REST request that fails for service and configuration requests, or the steps on the UI to reproduce the problem in case of administration GUI problem
  • Anything else that might be needed to fully reproduce your problem. Remember that in most cases being able to reproduce your problem locally is the only way to provide you with help.
Bug fixing works pretty much like answers on the mailing list: unless you have a support contract covering your needs you have to assume developers will look at the issue in their free time left besides work, family and their normal life.
If you can develop in Java the best way to get the problem solved quickly is to participate in the solution and contribute a fix. The more we are developing code, writing documentation and answering questions, the easier it will be to cover everybody's needs.