Mgraesslin: Replaced content with 'see [http://community.kde.org/KWin/Bugzilla KWin/Bugzilla in the Community Wiki]'

2011-02-27T14:33:22Z

Replaced content with 'see [http://community.kde.org/KWin/Bugzilla KWin/Bugzilla in the Community Wiki]'

Seli: New page: '''KWin bugreports''' == Handling priority == For the purpose of making handling of (not so small number of) KWin bugreports simpler, each bugreport should have a priority assigned, maki...

2009-01-06T15:14:37Z

New page: '''KWin bugreports''' == Handling priority == For the purpose of making handling of (not so small number of) KWin bugreports simpler, each bugreport should have a priority assigned, maki...

New page

'''KWin bugreports'''

== Handling priority ==

For the purpose of making handling of (not so small number of) KWin bugreports simpler, each bugreport should have a priority assigned, making it possible to sort the list of bugreports and see what bugreports should be handled first. For consistent setting of priorities, these rules should be followed:

=== Priorities ===

There are 5 priorities, VHI (highest), HI, NOR, LO, VLO:

* VHI - urgent, should be handled as soon as possible. Examples: Broken trunk, stable branch often crashing for many people, basic often-used feature not working properly, etc.
* HI - important, should be ideally fixed for the next release (meaning minor release, i.e. x.y.0). Examples: A crash that may happen for many people but is not critical, a basic but non-critical feature not working properly, very good idea for a new feature, etc.
* NOR - the default, no priority has been assigned yet (new bugreports get this priority and should get other priority assigned)
* LO - not important enough to be in the next release, low priority for when somebody will feel like fixing it. Examples: Relatively rare crash, not-often-used feature not working, feature request without important benefits, etc.
* VLO - minor issues, too specific or questionable (but still reasonable enough, complete nonsense or "nobody will ever do that" should be closed with WONTFIX).

A short simple way of explaining the priorities is "VHI ASAP, HI reasonably soon, LO somewhen, VLO who knows when".

=== Guidelines ===

It is important to note that these rules are just guidelines and do not need to be strictly followed when it makes sense (for example, a minor crash that should be however simple to fix can get HI in order to be checked before next release). Specifically, the examples given are just examples and the description of the priority should be used. The main purpose of these rules is to help with handling many bugreports, not to have rules for the sake of having rules. It is not a big problem if at the time of a KDE release there are tens of HI bugreports.

Wishes should use the same priorities like normal bugreports.

@@ Line 1: / Line 1: @@
-'''KWin bugreports'''
+see [http://community.kde.org/KWin/Bugzilla KWin/Bugzilla in the Community Wiki]
-−
-== Handling priority ==
-−
-For the purpose of making handling of (not so small number of) KWin bugreports simpler, each bugreport should have a priority assigned, making it possible to sort the list of bugreports and see what bugreports should be handled first. For consistent setting of priorities, these rules should be followed:
-−
-=== Priorities ===
-−
-There are 5 priorities, VHI (highest), HI, NOR, LO, VLO:
-−
-* VHI - urgent, should be handled as soon as possible. Examples: Broken trunk, stable branch often crashing for many people, basic often-used feature not working properly, etc.
-* HI - important, should be ideally fixed for the next release (meaning minor release, i.e. x.y.0). Examples: A crash that may happen for many people but is not critical, a basic but non-critical feature not working properly, very good idea for a new feature, etc.
-* NOR - the default, no priority has been assigned yet (new bugreports get this priority and should get other priority assigned)
-* LO - not important enough to be in the next release, low priority for when somebody will feel like fixing it. Examples: Relatively rare crash, not-often-used feature not working, feature request without important benefits, etc.
-* VLO - minor issues, too specific or questionable (but still reasonable enough, complete nonsense or "nobody will ever do that" should be closed with WONTFIX).
-−
-A short simple way of explaining the priorities is "VHI ASAP, HI reasonably soon, LO somewhen, VLO who knows when".
-−
-=== Guidelines ===
-−
-It is important to note that these rules are just guidelines and do not need to be strictly followed when it makes sense (for example, a minor crash that should be however simple to fix can get HI in order to be checked before next release). Specifically, the examples given are just examples and the description of the priority should be used. The main purpose of these rules is to help with handling many bugreports, not to have rules for the sake of having rules. It is not a big problem if at the time of a KDE release there are tens of HI bugreports.
-−
-Wishes should use the same priorities like normal bugreports.

Projects/KWin/Bugreports - Revision history

Mgraesslin: Replaced content with 'see [http://community.kde.org/KWin/Bugzilla KWin/Bugzilla in the Community Wiki]'

Seli: New page: '''KWin bugreports''' == Handling priority == For the purpose of making handling of (not so small number of) KWin bugreports simpler, each bugreport should have a priority assigned, maki...