search

ewiger / gc3pie

Automatically exported from code.google.com/p/gc3pie
0 stars 0 forks source link

Re-define bug report labels #287

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
The current set of bug tracker labels has not been revised or
substantially modified since the early stages of GC3Pie development,
and is getting more and more out-of-sync with the devlopment reality.

Please come up with a proposal on how to restructure/redefine the bug
tracking labels.

Original issue reported on code.google.com by riccardo.murri@gmail.com on 8 Aug 2012 at 7:01

GoogleCodeExporter commented 9 years ago 
For reference, here's some definitions used in the ARC/Nordugrid bugzilla:

> many of you are wondering what is the significance of Priority and Severity 
fields in Bugzilla. Here is some clarification, hammered out at today's TCG 
("core") meeting, which will also be added to the documentation.
> 
> *** Severity ***
> 
> To be used by bug submitters to indicate impact of the bug/issue. Bugs that 
prevent system from working are "blocker", bugs that are very bad and need lots 
of babysitting or workarounds are "critical", annoying bugs with simple 
workarounds are "major", nice-to-be-fixed bugs are "normal", minor problems are 
"minor", typos etc are "trivial". Improvements of existing functionality are 
"enhancement", and requests for new functionality are "feature request".
> 
> This severity/impact will be used also by release managers in order to assess 
release urgency, version number etc
> 
> Severity does not directly affect developers' schedule. Priority does.
> 
> 
> *** Priority ***
> 
> Indicates urgency with which the issue must be addressed.
> 
> P1 is top urgency; a developer who receives a P1 report should stop working 
on lower priority things and pay full attention to P1 issues. Severity of the 
issue does not matter! A feature request with P1 must be treated as the top 
priority as well as a blocking bug.
> 
> P2 is second-high priority, and so on - P5 being the lowest priority.

Original comment by riccardo.murri@gmail.com on 8 Aug 2012 at 7:02

GoogleCodeExporter commented 9 years ago 
My suggestion is to revise open issues by its authors and update them according 
to the NorduGrid guidelines above. We can introduce the labels that introduce 
priorities and severity level.

In my case a revision is a simple task :) but I guess it may be problematic for 
others.

Original comment by lukasz.m...@gmail.com on 8 Aug 2012 at 7:45

GoogleCodeExporter commented 9 years ago

Original comment by riccardo.murri@gmail.com on 17 Aug 2012 at 11:46

GoogleCodeExporter commented 9 years ago

Original comment by riccardo.murri@gmail.com on 17 Aug 2012 at 1:32