Bug Report writing Guidelines

Effective bug reports are the most likely to be fixed. These guidelines explain how to write such reports.

Please keep in mind: The GitHub issue tracker is NOT a support forum! You must not report questions or support inquires! We will close all issues of this kind without further explanations!

Before reporting a bug please make every effort to resolve the problem yourself! Upgrade to the most recent version of deegree (Download from www.deegree.org/download). If the issue remains, then check the Open Bugs Report if a similar issue has been reported. Tip: You can vote on an issue using GitHub reactions!

If the issue persists and has not been reported by other users we encourage you to submit a bug report here https://github.com/deegree/deegree3/issues/new. Please add all information available. See our checklist for more information.

Checklist

• Title: Enter a clear and meaningful summary
• Description field must include:
  • Steps to Reproduce
  • Actual and expected behaviour
  • deegree version
  • Additional information on runtime environment, database, ...
  • attach the complete deegree workspace for the reproducer (or use a gist)

General Principles

• Be precise
• Be clear - explain it so others can reproduce the bug
• One bug per report
• No bug is too trivial to report - small bugs may hide big bugs
• Clearly separate fact from speculation

Reporting a security vulnerability

If you encounter a security vulnerability in deegree please take care to report the issue in a responsible fashion:

• Keep exploit details out of the issue report (send to TMC privately – just like you would do for sensitive sample data) Mark the issue as a vulnerability!
• Be prepared to work with Technical Management Committee (TMC) members on a solution!
• Keep in mind TMC members are volunteers and an extensive fix may require fundraising and other kinds of contributions!

see also our security policy.

Ticket lifecycle

• After submitting a bug report the ticket will have state open. In this state the TMC or the reporter will search for volunteers to fix this bug (label contribution welcome or funding welcome).
• After funding is clarified, and a developer is available the assignee will change to the assigned developer.
• As soon as a developer has accepted to solve the bug the ticket will change to state in progress.
• The assigned developer implements the bug fix and provides a pull request. When the work is finished, and the pull request is accepted by the TMC the issue and the related pull request will change to state CLOSED.
• On rare occasion that no founding or contribution is provided, the TMC will close an issue without further explanations after a longer period of inactivity (approx. 1 year) with the label "wontfix".