Jump to content

Krita/Docs/BugsPriorityHowto

From KDE Community Wiki
Revision as of 20:51, 24 January 2016 by Dmitry (talk | contribs) (Bug task format)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Bugs Priority HOWTO

We have quite a lot of bugs and wishes on bugzilla, so we have to decide, what bugs are real priority, and what are not. Here is a proposal of how to manage this problem.

Phabricator columns for priority bugs

There are four columns for bugs in this workboard on the phabricator.

  • Needs Info — the bug has been checked/answered by a developer, but it needs more info from the community. It might need some more details, comments or GUI designs. After staying in this column for too long, it might be deleted.
  • Minor Fix — quick reproducible bug that can be fixed in spare time in a couple of hours.
  • Triaged — usual bugs that should be worked on. Preferably, the bug should be reproducible. If not, it will be moved back to Needs Info column. The bugs at the top has higher priority than the ones at the bottom.

General recommendations

  1. If the bug is really small and easy to fix (< 1 day of work), put it into the Minor Fix column in the order of importance.
  2. If the bug is complex enough, make sure the bug is reproducible (preferably, ask on IRC) and put it into the Triaged column.
  3. If there are some bugs in the Needs Info, it might be probable, that someone in the community should be poked to answer additional question. When the question is answered, put the bug back to an appropriate column.

Bug task format

No additional information is needed. Just put (probably, in your own words) the short name of the bug in a title, and put a link to a bugzilla to the content of the bug.

Example: T457