Jump to content

Krita/Docs/Bug Naming Policy: Difference between revisions

From KDE Community Wiki
Dmitry (talk | contribs)
Created page with "== Bug rotation workwlow == ; UNCONFIRMED : initially a bug comes in this state, when being triaged the bug should move either into CONFIRMED or NEEDSINFO ; CONFIRMED : at l..."
 
Dmitry (talk | contribs)
No edit summary
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Bug rotation workwlow ==
== Bugs stateflow ==


; UNCONFIRMED
; UNCONFIRMED
Line 12: Line 12:
; ASSIGNED + 'reproducible' keyword
; ASSIGNED + 'reproducible' keyword
: the developer managed to reproduce this bug
: the developer managed to reproduce this bug
; NEEDSINFO
: neither developer nor community members could reproduce this bug and need some more info from the reporter. When answering the reporter should reset this bug into UNCONFIRMED state again. After a month without a reply from a reporter the developers will close the bug as WORKSFORME
User notice text:
<blockquote>
I have marked the bug as NEEDSINFO. Please test it and if you still encounter it, please add your comment and reopen the report by setting it to REOPENED state. If not, close it by adding a comment and setting RESOLVED/FIXED state.
</blockquote>
; WORKSFORME
: when neither developers nor a community can reproduce the bug and the reporter cannot provide any more information. This bug can still be reopened by the users.
User notice text:
<blockquote>
The developers did not find a way to reproduce the bug, so it was marked as RESOLVED/WORKSFORME. If you still encounter this bug, please add your comment and reopen the report by setting it to REOPENED state.
</blockquote>
== Wishes stateflow ==
; Wish + UNCONFIRMED
: a wish is reported by a user.
; Wish + CONFIRMED
: a wish is confirmed by the community to be a valid feature for Krita
; Task + CONFIRMED + 'future_project' keyword
: a wish can be considered as the next Kickstarter stretchgoal or just a nice project for developers to work on. The task should be complete enough to work on, e.g. have drafts and/or mockups

Latest revision as of 09:16, 5 July 2015

Bugs stateflow

UNCONFIRMED
initially a bug comes in this state, when being triaged the bug should move either into CONFIRMED or NEEDSINFO
CONFIRMED
at least one developer or a member of Krita community managed to reproduce this bug. The bug in this state should be clear enough so the developers could reproduce it on their own computer. Please consult this guideline to check if there is enough information in the bug.
ASSIGNED
the developer took this bug but didn't manage to reproduce it yet
ASSIGNED + 'reproducible' keyword
the developer managed to reproduce this bug
NEEDSINFO
neither developer nor community members could reproduce this bug and need some more info from the reporter. When answering the reporter should reset this bug into UNCONFIRMED state again. After a month without a reply from a reporter the developers will close the bug as WORKSFORME

User notice text:

I have marked the bug as NEEDSINFO. Please test it and if you still encounter it, please add your comment and reopen the report by setting it to REOPENED state. If not, close it by adding a comment and setting RESOLVED/FIXED state.


WORKSFORME
when neither developers nor a community can reproduce the bug and the reporter cannot provide any more information. This bug can still be reopened by the users.

User notice text:

The developers did not find a way to reproduce the bug, so it was marked as RESOLVED/WORKSFORME. If you still encounter this bug, please add your comment and reopen the report by setting it to REOPENED state.

Wishes stateflow

Wish + UNCONFIRMED
a wish is reported by a user.
Wish + CONFIRMED
a wish is confirmed by the community to be a valid feature for Krita
Task + CONFIRMED + 'future_project' keyword
a wish can be considered as the next Kickstarter stretchgoal or just a nice project for developers to work on. The task should be complete enough to work on, e.g. have drafts and/or mockups