You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 

3.3 KiB

Issue Tracking

All changes to the ODO software must base on an issue of the codeberg issue tracking system. Any bugs or change request must be entered there as issues. Before adding a new issue, check if it has already been reported.

Labels and states

Issues may be flagged using one or more of the followig labels:

Label Meaning
Bug Some kind of defect or unexpected behavior in the software
CodeQuality A suggestion to enhance the code quality
Documentation A suggestion to enhance or correct the documentation
Feature A new feature to implement
Legal A legal issue in the software or its documentation
Performance A suggestion to enhance the performance
UI A suggestion to enhance the user interface
FixDescription The description of the issue needs to be improved
Sporadic The issue is not well reproducible
QM An issue relate to the quality management system itself
Version:XXX The issue occurred in software version XXX
Branch:XXX The issue is being fixed on branch XXX

An issue is approved by assigning a milestone to it. This milestone also defines the software version, where it will be resolved.Only approved issues (i.e. with a valid milestone) may be processed.

When an issue is started, one or more users are assigned responsible for it. This may be done by the users themselves. The implementation of the issue is then done according to the coding guideline.

After the issue is done, it is closed.

Issue description

The issue description must be short, precise and complete and require as few follow-up questions as possible.

Bugs

For bugs, the follwing aspects should be covered:

  • Software version: The version number displayed in the about section of the software. If this ends with 'SNAPSHOT', also the branch and revision number it was built from are useful.
  • Environment: Hardware (incl. important details, e.g. CPU, RAM), OS (incl. version), JVM version.
  • Steps to reproduce
  • If applicable
    • The ODO-app which triggered the issue
    • Exception stack trace
    • Log files
    • The data which was used to trigger the issue

Feature requests

Feature requests shall be written as user stories in the form As a <role> I want <action> to achieve <goal> (or similar). It shall also include a list of clear acceptance criteria.

Other types of issues

Clearly describe what the point is.