Skip to content

Bug Report writing Guidelines

Jump to bottom
tfr42 edited this page Oct 17, 2023 · 21 revisions

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".
Clone this wiki locally