Bugzilla Policies

This document describes nangu.TV uses of several Bugzilla fields and presents policies and processes witch are applied in issue tracking system.

Please follow the standard best practices for writing bugreports. You can review the following sites for inspiration:

Severity

Severity field is typically used by requester (e.g. customer). It shows how is this issue perceived by requester.

sla-critical:

  • this issue is requested to be covered by SLA
  • it has severity “Critical” according to signed SLA

sla-major:

  • this issue is requested to be covered by SLA
  • it has severity “Major” according to signed SLA

sla-minor:

  • this issue is requested to be covered by SLA
  • it has severity “Minor” according to signed SLA

critical:

  • critical problem which is seriously affecting the service
  • problem which renders services unusable
  • more then 10% of users are affected

major:

  • serious problem with impact on the service but not rendering it unusable

normal:

  • default value
  • normal issues, day-to-day stuff

minor:

  • minor issue
  • small improvement, feature proposal etc.

SLA Workflow

Currently deployed policy requires to use severity field for signalling, that the particular issue should be treated as SLA issue. Following can happen:

  • severity can change in time, e.g. from sla-major to sla-minor (e.g. after deploying workaround or when it turned out that previous level was inaccurate)
  • severity can be changed to non sla (e.g. major), when the either side believes that the issue is fixed or not under SLA anymore (e.g. fix has been deployed, but issue should remain open to collect feedback)
  • issue can be closed opportunistically (e.g. fix deployed), it is expected that issue will be reopened in case that either side is not satisfied with solution

Please, take seriously marking issues as SLA as it is vital information which is used by other systems to monitor progress, do autoescallation etc.

Priority

Field Priority is dedicated for internal usage by nangu.TV team. Please, do not change Priority without asking issue owner (assignee) or bug masters.

P1 bugs
are for immediate attention
have to be resolved till the release date (is release_milestone is set)
P2 and P3 bugs
used for better granularity of bug organization
it could happen that not all of them will be fixed within the planned release_milestone
P4 bugs
could easily slip between releases
P5 bugs
“free time” bugs

Status

Status shows the current issue status:

NEW
new issue, which has not been taken care of
ASSIGNED
assignee of this bug is demonstrating that he/she is working on this issue
REOPENED
similar to NEW but for once closed issues
must be used if requesting feedback on already resolved issues, e.g. fix is not working etc.
RESOLVED
problem is resolved / fixed
all bugs in this stat will be processed by QA department
VERIFIED
internal issue, which has been already tested by QA deparment
all bugs in this stat will NOT be processed by QA department
state is set by QA department
CLOSED
resolved issues which doesn't need any further attention
all bugs in this stat will NOT be processed by QA department

Resolution

States RESOVED, VERIFIED and CLOSED have additional substate – resolution. All these states are understood as final (issue could be reopened by setting the status to REOPEN), so this means, that nobody is really working on such issues.

FIXED
issue has been resolved / fixed
INVALID
issue has been closed because is not valid
this could mean that request was bogus or doesn't include valid information etc.
WONTFIX
we believe that this is not a problem, e.g. reported behavior of application is feature and not a bug
DUPLICATE
reported issue is duplicate of listed bug and will not be used for progress tracking
WORKSFORME
we are not able to reproduce this bug
EXPIRED
bug was closed for inactivity
if you want to reply to the bug and make a follow up, please reopen it

Workflow

There are two main concepts of workflow. All features and bugs which are not planned to the upcomming release should be in product Features. Issue which are not yet assigned, should be assigned to *-bug-dispatcher accounts. These accounts are used as work-buckets for the particular teams.

Bugs assigned to the particular people mean that this particular person is working on the issue and should deliver the resolution as expected.

Features

If you are writing generic feature (change) request, please use English to enable other customers to review the request and follow the implementation.

Tickets assigned to features@nangu.tv and/or in Features product are considered as proposals or requests. They are not under active development until release_milestone is assigned. They are then typically reassigned to appropriate dispatcher or actual person. They are typically evaluated right after insertion and then during release planning cycle. In case that customer needs assured date of implementation or wants to be certain about the actual inclusion in release, he or she is encouraged to contact us at sales@nangu.tv.

Procedure is described in detail in Platform introduction guide.

Tags: