Bug Report writing Guidelines - deegree/deegree3 Wiki
Bug Report writing Guidelines
Effective bug reports are the most likely to be fixed. These guidelines explain how to write such reports.
But 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.
- 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)
- 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.
- 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 explainations after a longer period of inactivity (approx. 1 year) with the label "wontfix".