Bugs and features triaging - darktable-org/darktable GitHub Wiki

This is a proposal of labels for triaging issues (bugs and feature requests) in a meaningful way, in order to let new contributors find topics to work on depending on their area of expertise and interests:

All issues

  • Scope: what part of the workflow is the issue about ?
    • UI: user interface and interactions
    • CLI: running darktable in command-line
    • image processing: correcting pixels
    • digital assets management: files, collections, archiving, tags, etc.
    • hardware support: dealing with drivers and external devices: GPU, printers
    • software support: wiring external libs and software: LittleCMS, colord, G'MIC, enfuse/enblend, etc.
    • performance: doing everything the same but faster
    • color management: ensuring consistency of colour adaptation through display/output profiles
    • OS support: making darktable work on particular operating systems
    • code base: making darktable source code easier to manage
    • translation: make darktable international
    • camera support: adding WB and raw support for new cameras
    • noise profiles: adding noise profiles for new cameras
    • user manual: improving the documentation
  • Difficulty: how hard will be the change ?
    • hard: big changes across different parts of the code base
    • average: some changes across different parts of the code base
    • trivial: some changes in a couple of functions
  • Priority: how urgent is this ?
    • high: core features are broken and not usable at all, software crashes, …
    • medium: core features are degraded in a way that is still mostly usable, software stutters…
    • low: core features work as expected, only secondary/optional features don't

Bugs only

  • Reproducibility: how consistent is the bug ?
    • confirmed: a way to make the bug re-appear 99% of times has been found
    • random: the bug appears more than 30% of times but the causes are still unclear
    • peculiar: the bug seems to affect only a specific target and cannot be reproduced elsewhere
  • Understandability: do the developers have enough info to start working ?
    • clear: devs have a complete bug report with all the relevant info to start fixing
    • incomplete: devs lack some important info to start fixing
    • unclear: devs lack most or all important info and can do nothing, the report will be closed after 2 weeks if not improved
  • Follow-up: how advanced is the fix ?
    • pending: someone needs to start working on that
    • work in progress: someone is currently working on that, check with them before taking over
    • won't fix: the bug needs a fix outside of the scope of darktable, at a theoretical level (maths/physics), or needs a complete rewrite of the application
    • upstream: the bug needs a fix outside of the scope of darktable, in an external lib or in a driver
    • invalid: the bug is not a bug, but a feature. Such bugs are usually a hint that the user manual should be improved (or read)

Features requests only

  • Feature kind:
    • new: new features to add
    • enhancement: current features to improve
    • redesign: current features to rewrite