Feature #3366: Rename the "Tracker" field to "Severity" - Redmine

Actions

Copy link

Feature #3366

closed

Rename the "Tracker" field to "Severity"

Added by Robert Pollak over 15 years ago. Updated almost 15 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Jean-Philippe Lang

Category:

Issues

Target version:

Start date:

2009-05-15

Due date:

% Done:

Estimated time:

Resolution:

Description

Reason: I'd like to use this field not just for "bug" or "feature", but with more values, as in Bugzilla:

Severity
This field describes the impact of a bug.
Blocker     Blocks development and/or testing work
Critical    crashes, loss of data, severe memory leak
Major       major loss of function
Normal      regular issue, some loss of functionality under specific circumstances
Minor       minor loss of function, or other problem where easy workaround is present
Trivial     cosmetic problem like misspelled words or misaligned text
Enhancement Request for enhancement

Note that this severity is orthogonal to "priority": There can be trivial misspellings that are very nasty and therefore have high priority, and there can be crashes that appear so seldom or irreproducible that fixing them has low priority.

Using "severity" also makes it very visible that there should be no separate patch tracker,
but the patch should be an attachment to the corresponding bug or feature issue.

Actions

Copy link

Updated by Zarooba Rozruba over 15 years ago

I don't understand this request. Tracker implies type of work:

Bug - code that is broken, needs fixing. Aka: code that is written against design document, but does not do what design document specifies.
Feature - adding of new code, new functionality. Aka: code that is outside of scope of original design document.
Support - non code related work, password change, setting change, etc.

What you are proposing is a new field, and Redmine already supports adding new fields.
Please head into Administration -> Custom Fields -> and click ''new custom field''. Specify List format, and indicate if it is required field, and if should automatically be added to all projects.

You can now track your Severities, however confusing they can be to your users.

Actions

Copy link

Updated by Robert Pollak over 15 years ago

Status changed from New to Resolved

I see.
So for my use case, I'd simply reconfigure to only have a single tracker e.g. called "Issues",
and a custom field "Severity" (where "Support" is an additional value).

Actions

Copy link

Updated by Zarooba Rozruba over 15 years ago

actually, you could still have two trackers.

Support vs Problem

Where support is any help (and has typical priority)
While problem would have 'Severity' field

Please do notice that when you are in Administration -> Custom Fields, you can specify on which tracker a field should be active. So a problem could have severities enabled on top of priorities, while Support would operate on priorities alone.

ps: not sure if Enhancement is a severity?
ps: tracker is to help you track reason of an issue. Is it because client wants something new (feature) or because developer screwed up (bug), or because the server flakey/administrative tools lacking (support).

Actions

Copy link