Krita/Docs/BugsPriorityHowto: Difference between revisions

From KDE Community Wiki
< Krita‎ | Docs
No edit summary
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Dmitry's Wokrboard howto ==
= 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 [https://phabricator.kde.org/project/board/9/ this workboard] on the phabricator.
There are four columns for bugs in [https://phabricator.kde.org/project/board/9/ this workboard] on the phabricator.
* '''Needs Info''' &mdash; the bug has been checked/answered, but it needs more info from the community. It might need some more details, comments or GUI designs.
* '''Needs Info''' &mdash; 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''' &mdash; quick reproducible bug that can be fixed in spare time in a couple of hours.
* '''Minor Fix''' &mdash; quick reproducible bug that can be fixed in spare time in a couple of hours.
* '''Triaged''' &mdash; 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.
* '''Triaged''' &mdash; 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.


So the general recommendations are:
== General recommendations ==
# 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
# 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.
# If the bug is complex enough, make sure the bug is reproducible (preferably, ask on IRC) and put it into the '''Triaged''' column.
# If the bug is complex enough, make sure the bug is reproducible (preferably, ask on IRC) and put it into the '''Triaged''' column.
# 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: [https://phabricator.kde.org/T457 T457]

Latest revision as of 20:51, 24 January 2016

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