GeoServer AI policy

Contributors and users may use AI tools to assist in project activities. However, to maintain code quality, project security, and a healthy community, we require all contributors to adhere to the following policy.

Code & Documentation Contributions

All contributions must meet the following requirements, regardless of how they are produced:

  1. Responsibility: The submitting contributor takes full responsibility for the contribution - its correctness, design, copyright, licensing and fitness for the project - regardless of how it was produced.
  2. Understanding: The contributor must fully understand every part of the contribution - its design, implementation, and implications. Contributions that cannot be explained should not be submitted.
  3. Correctness: The contributor is responsible for verifying that the contribution is correct, complete, and consistent with the project architecture and conventions. AI tools make mistakes; catching them is the contributor's responsibility.
  4. Feasibility: Contributions must not exceed what the contributor could have produced independently, with reasonable research and peer discussion. AI tools accelerate work; they do not substitute for the expertise required to do it.
  5. Maintainability: Contributions must be maintainable by the contributor and other project members over time. Unnecessary complexity and verboseness, either in code or documentation, are a long-term liability and should be avoided.

Security reports

AI tools may be used to help find and write up a vulnerability report, but the reporter is responsible for verifying the issue is real and reproducible before submitting. Reports must include a working reproduction (code, request, or config) against a supported GeoServer series, not just a plausible-sounding description. Reports that turn out to be hallucinated or unverifiable will be closed without further engagement.

Community & Human Communication

The following guidelines apply to human communication channels.

The main general rule is to keep messages short and to the point; few will have the time and inclination to read long, detailed prose:

  • State your point clearly in the first sentence (this is where the reader decides if it's worth checking the whole message)
  • Be respectful of the reader's time, keep the whole message to about one screen; if it's genuinely longer, add details in a follow-up section that can be skipped without losing the major points.
  • One concern/topic per message.
  • Not all participants will be native English speakers; keep the conversation simple and use common wording.
  • Avoid heavy AI-style formatting (headers, bold key terms, exhaustive bullet nesting) even for short messages; if it looks like AI slop, readers will discount the message before engaging with its content.

The general rules apply to all channels (Discourse included). What follows are quick additional indications for specific channels.

For communications in pull requests:

  • Feedback on code goes primarily inline on the diff line it concerns.
  • A top-level comment is for things that don't anchor to a line (overall approach, missing tests, scope).
  • When referring to code/documentation not contained in the PR, add a link to it.

For issues in the issue tracker:

  • Title names the observed symptom, not your diagnosis of the cause
  • Description: expected vs. actual behavior, repro steps as a list only when steps are genuinely sequential
  • Add small data samples, configuration, and requests to reproduce the issue on somebody else's machine