Separate enhancements from severity field / Bug classification field

NEW
Unassigned

Status

()

Bugzilla
Creating/Changing Bugs
P1
enhancement
18 years ago
3 years ago

People

(Reporter: CodeMachine, Unassigned)

Tracking

(Blocks: 1 bug)

Dependency tree / graph

Details

(Whiteboard: Comment 63)

Attachments

(2 attachments, 4 obsolete attachments)

(Reporter)

Description

18 years ago
The current severity field implies enhancements are a severity on their own -
but they're not really.  Enhancements could be critical, minor, trivial, etc.
Even Netscape-required-by-milestone-x features are "enhancements" if they're not
currently in the code base.

By removing the "enhancement" severity, and adding an enhancement/bug choice,
enhancements could get severities.  Without this, enhancements will continue to
be listed as bugs as a workaround.
I have to agree with this. Enhancement really should be a seperate field. I see
enhancements marked as "major P2" all the time because of this problem.
Instead, people are starting to use the summary and whiteboard fields to add
  RFE: [FEATURE] {feature}
...and many other types of markers to indicate that a bug is really an
enhancement request.

Updated

18 years ago
Severity: normal → enhancement
Status: NEW → ASSIGNED
Priority: P3 → P4
I'm voting for this, and echoing my sentiment. :)  I've had people ask already 
"how do I mark it as a new feature?"  Most of them never thought of looking at 
the severity field, because it's not obvious.

Comment 3

17 years ago
tara@tequilarista.org is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
Status: ASSIGNED → NEW

Comment 4

17 years ago
an enhancement is more of a bug classification type (crasher, enhancement, UI, 
feature failure, documentation) than a severity. i'm wondering if it would make 
sense to even take a stab at defining a classification type.
Assignee: tara → cyeh
(Reporter)

Comment 5

17 years ago
I'm not necesssarily disagreeing with the idea of classification types, but the
things you mention here can already be supported as far as I can see.

crasher - bug, highest severity, possibly crasher keyword
UI - component, or set of components, can have enhancements or bugs
feature failure - a bug?
documentation - a component as well, can have enhancements or bugs

We could implement an enhancement keyword, but it would be overlooked by
submitters I think.
I think this should be in 2.12.  It might be a minor schema change, but it 
should be a relatively simple change to make.

checksetup.pl would need to:
1) create the new column, default it to the 'bug' state
2) search for any bugs with an enhancement severity, and set the new column to 
'enhancement', and the severity back to 'normal'
3) change the definition of the severity column to remove 'enhancement' from it.

Since part of the schema change thing was to eliminate all of the ENUM() column 
types, this would be a real easy change to make at the same time as you're doing 
that.
Whiteboard: 2.12

Comment 7

17 years ago
I like the idea of pulling enhancments out of the severity field.  However, I
think that 'bug' is too overloaded, generic and even cute, so if we're going to
use something to distinguish the default bug classification from enhancement
requests, how about using 'defect'?  Are we going to leave it at two categories,
or could we add other things the bug system is being used for, such as assigned
tasks, programmer's notes to themselves, or what-have-you?
There ya go, Chris...  there's your excuse to make it a full classification 
type.  That actually makes sense.  Classification = ( bug report | enhancement | 
assigned task ) and other things that would make sense here.
(Reporter)

Comment 9

17 years ago
Yes, one benefit of this being a classification type would be that you would not
have to have a "bug" type, and would help Bugzilla to be used for other sorts of
tasks that have nothing to do with software.

There are certainly other software oriented things hanging around of course, to
fully fix this would require modularity (bug #13540).

Comment 10

17 years ago
i think this is the best way to go. however, this is going to require some 
schema juggling and some fairly invasive work that i don't want to bite off for 
2.12. dropping from the 2.12 candidate list. if someone coughs up a patch, i'll 
consider putting it back on.
Whiteboard: 2.12

Comment 11

17 years ago
Please keep in mind that the more fields Bugzilla has, the more effort is 
required to file a bug. I don't think a `bug classification' field would be 
useful enough to warrant inclusion in Bugzilla.
(Reporter)

Comment 12

17 years ago
mpt, are you saying we should nuke enhancement altogether?
QA Contact: matty
Whiteboard: 2.14

Comment 13

17 years ago
No, just that you shouldn't make new fields unless they're *really* necessary --
and I don't think this one is. Ideally we should be trying to reduce the number
of fields, not increase them.
(Reporter)

Comment 14

17 years ago
The point is that it is currently confusing and harmful.  Hence we should either
separate it or get rid of it altogether.
Wow, didn't know that this bug exists, and even such an old one. Great, so I
don't need to file it :) I strongly agree that the severity field is the wrong
place for the bug/rfe distinction. It should go away from there soon.

Bug type classification for mozilla.org is bug 65965. It suggests to use either
keywords or a dropdown box like the current version field. (And I was already
wondering why nobody had thought of it earlier...)
This is a severe bug in the bugzilla design (not being able to assign severity
to enhancement requests). Marking as such.
Severity: enhancement → major

Comment 17

17 years ago
an RFE keyword would be fine w/ me.  We're abusing the bug name field w/ [RFE].

Updated

17 years ago
Whiteboard: 2.14 → 2.16
moving to real milestones...
Target Milestone: --- → Bugzilla 2.16

Comment 19

17 years ago
*** Bug 71446 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

16 years ago
Priority: P4 → P3
Taking all of cyeh's Bugzilla bugs.
Assignee: Chris.Yeh → justdave

Comment 21

16 years ago
Issuezilla has this, and i've been reviewing their initial patches, I'll 
probably try to split them into 3 categories: Bogus, Nomen, Improv.
Can you explain the three concepts a bit?
Bogus: something is wrong? (=the former correctness keyword?)
Nomen: ???
Improv(ement): something should be made better (i.e. a feature should be made
more usable, or an entirely new feature should be added)?

How is your proposal related to bug 65965 (the bug type categorization)?
-> Bugzilla product, General component.
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified

Updated

16 years ago
Whiteboard: 2.16

Comment 24

16 years ago
I realize this is off-topic, but I did not find a more appropriate bug either.

Regarding mpt's comment about reducing fields, I do not see a lot of superfluous
fields.  However, I do wonder how often it is necessary to have two fields for
specifying platform and OS.
We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18

Comment 26

16 years ago
Created attachment 61866 [details] [diff] [review]
Adds bug_type to schema, enter_bug, show_bug, query & buglist

A _simple_ high level break down of bug types is required for our installation.
 Keywords have the power-user feel to them, meaning bugs would not be properly
classified when entered by users, support staff or managers.  Finer granularity
in classification can be achieved with keywords after the assigned engineer has
completed an analysis of the problem.
Comment on attachment 61866 [details] [diff] [review]
Adds bug_type to schema, enter_bug, show_bug, query & buglist

John, you are my hero. :-)

Still, this needs some more work. Here are the problems I got when I applied
the patch:
- For some reason, patching the file template/default/query/query.atml did not
work non-interactively, but only after entering the file name manually.
- AddField("bugs", "bug_type", ...); was missing from checksetup.pl, thus I got
an error when it tried to CheckEnumField with the non-existing column. I added
an entry fairly at the end like this, and removed the CheckEnumField above:

2600a2619,2623
> # 200x-xx-xx xxx@xxx.xxx bugxxxx(9412?, 65965?):
> # Add a field for the bug type to the bugs table.
> AddField("bugs", "bug_type", "enum($my_types) not null");
> CheckEnumField('bugs', 'bug_type',     @my_types);
>

- The "Target Milestone" select box is badly placed in the show_bug form. This
may be a completely unrelated bug. I changed the following in bug_form.pl, but
the rowspan will have to be computed from the usetargetmilestone parameter.
  1. added a cell <TD>nbsp;</TD> here:

<TD>&nbsp;</TD>
<TD ALIGN=RIGHT><A href=\"$url\"><B>Target Milestone:</B></A></TD>
<TD><SELECT NAME=target_milestone>" .
    make_options($::target_milestone{$bug{'product'}},
		 $bug{'target_milestone'}) .
		     "</SELECT></TD>

  2. Changed rowspan from 4 to 3 here:
  <TD>&nbsp;</TD>
    <TD ROWSPAN=3 ALIGN=RIGHT VALIGN=TOP><B>CC:</B></TD>
    <TD ROWSPAN=3 VALIGN=TOP> $cc_element </TD>

- I can't get the bug_type displayed in a buglist. The option seems to be
missing from colchange.cgi.

Thanks for the work. I would love to see this added to bugzillla soon; I think
it would be a good solution to both bug 65965 and this one.
Attachment #61866 - Flags: review-

Comment 28

16 years ago
i was speaking of the actual patches to get from 'bugzilla' => issuezilla
Nomen(clature) - renaming 'bug' => 'issue'
Bogus - eg renaming 'debug' => 'deissue'
Improv(ement) - the actually useful bits of their patches

http://www.openoffice.org/issues/bug_status.html#issue_type
http://www.netbeans.org/issues/bug_status.html#issue_type
Issue Type   This field describes the type of issue. 
Defect       an issue in existing feature/functionality
Enhancement  Improvement to existing feature
Feature      new feature
Task         A task associated with instantiation, or in support of a 
feature/enhancement/issue.
Patch        A software patch submitted to fix a defect.
- You can test the patch (including the modifications described above) here:
	http://bugzilla.mathweb.org:8000/show_bug.cgi?id=1

- Note that I'm not receiving bugmail, so if you want me to test something,
please email me directly.

- This patch will probably conflict with the pending templatization patches in
bug 103778 (buglist.cgi) and bug 103953 "Templatise enter_bug.cgi", so probably
those patches should be applied first, and then this one should be re-created as
a diff against a patched version.

- To solve bug 65965 along with this one, the enum values for bug_type might
include something like: 
	Stability - Crash
	Stability - Hang
	Correctness - Standards
	Correctness - other
	Performance - CPU
	Performance - RAM
	Security & Privacy
	Usability & Specs
	Polish
	Code - API
	Code - Modularization, Packaging, Versioning
	Code - Other Cleanup
	New Feature / Default Configuration
	Other - Tracking
	Other
maybe also these:
	Documentation - User
	Documentation - MozDev
	Documentation - WebDev
This would get rid of some keywords (crash, hang, perf, footprint, ...). If it
included the documentation things, it would make sense to allow for different
default assignees for different bug types.
timeless: Thanks for the explanation. This clears things up.

John: I can't get the bug entry form to work correctly for some reason. The type
field is displayed on the entry form, but the bug is still posted with the
default value...

Comment 31

16 years ago
Created attachment 61936 [details] [diff] [review]
v2

Fixes checksetup and bug_form; bug_post and colchange now also work.  Thanks
for the input.

Comment 32

16 years ago
i think i'd prefer inquiry over question.

The NSCP people seem to need a Project status, if they could select a term i 
think we could probably get it in the initial version.

Comment 33

16 years ago
Created attachment 61940 [details] [diff] [review]
v3: QUESTION->INQUIRY and explaination in bug_status.html
Comment on attachment 61940 [details] [diff] [review]
v3: QUESTION->INQUIRY and explaination in bug_status.html

As far as I can tell, attachment 61940 [details] [diff] [review] works as advertised. (I don't think
INQUIRY is better than QUESTION, but let's not argue about that now. Also, I'd
prefer BUG over DEFECT.)

Mass change support (the "Change several bugs at once" link from bug lists)
does not offer to change the bug type yet, but I'm not sure if that's necessary
for this patch to land. (Well, maybe it would be good to have it to change all
existing bugs with severity=enhancement at once.)

In bug_form.pl, there's either a misindenation or an unexpanded tab:
	 priority,
+	bug_type,
	 bug_severity,

r=afranke. Second review still needed.
Attachment #61940 - Flags: review+

Updated

16 years ago
Keywords: patch, review
With the enter_bug templatization patch applied, the following files have to be
patched differently:

- enter_bug.cgi:

1. add @legal_type in use vars qw( ... ), e.g.:
  [...]
  @legal_priority
  @legal_type
  @legal_severity
  [...]

2. add these two lines somewhere, e.g. the corresponding bug_severity stuff:

$vars->{'bug_type'} = \@legal_type;
$default{'bug_type'} = formvalue('bug_type', 'DEFECT'); #Param('defaulttype')

- enter_bug.tmpl:

  after the bug_severity INCLUDE there's a <td colspan="3">; change the <tr> to:
  <tr>
    [% sel = { nicename => 'Bug Type', name => 'bug_type' } %]
    [% INCLUDE select %]

    <td colspan="2"></td>
  </tr>

Comment 36

16 years ago
Created attachment 62141 [details] [diff] [review]
v4 - Adds mass change of bug_type to buglist and fixes indentation

As all existing bugs have a null type, any existing installation will need the
mass change, as we did, so here it is.	This patch is now in production at our
site.

Comment 37

16 years ago
Here's my design concept for a 'bug type' field, based on what I see in Bugzilla
at mozilla.org:

* actual bugs (aka defects)
* enhancement requests
-- currently using severity field
* tracking bugs (aka meta bugs) ("What bugs make Mozilla advocacy harder?")
-- currently uses 'meta' keyword
* one-time task (not a bug or a feature request, but still a one-time project)
--currently not distinguished -- not sure if this is really a neccessary type
* inquiry bugs ("What should we do about X?")
-- currently not distinguished.
* Reminder / permanent task bugs (e.g. the bug about turning off MacsBug
debugging tables before each milestone, but leaving them in on the trunk, always)
--currently not distinguished -- seems to be rare in Mozilla except for metas. 
But confuses a lot of people.

Characteristics of this classification:
* The choices are exclusive of one another (hence, keywords are not the best method)
* The classification is orthogonal to most of the exisiting fields (severity,
platform, priority, product, component, version).  Any of these types of 'bugs'
could have different severities, platforms, priorities, products, components, or
even versions.
* Certain existing fields are only relevant for some types (status, resolution,
and target milestone in their current form are probably irrelevant for tracking
bugs); however, putting these classifications into one of those fields wouldn't
work because they are relevant for two or more types.  And anyhow it would be
confusing.

These seem to be appropriate characteristics for a 'bug type' field. 
 Many of the other things suggested for a 'bug type' field seem more suitable
for other places:
* 'new feature' vs. 'feature enhancement' is extremely subjective; I'm not even
sure how to tell the difference.
* 'documentation' really belongs as a component.  It's not orthogonal to
bug/enhancement/tracking.  Similarly for 'default configuration'.
* 'hang' and 'crash' are always types of bugs (never enhancement requests), but
might also be appropriate for tracking bugs.
* 'performance' really could go on bugs, enhancement requests, tracking bugs,
tasks, etc.
* 'patch' belongs where it is: in the attachments field of a bug.  (Although
possibly it would be nice to have multiple bugs be able to share an attachment
easily.)  You can have patches for bugs, enhancement requests, tasks, inquiries,
etc.

I think a 'bug type' or 'issue type' field of this sort would be a valuable
enhancement to Bugzilla and would clarify the status of a lot of bugs.  I think
it would not confuse submitters, since the default would be 'bug', and those
which aren't 'bug' or 'enhancement request' will mostly be used by developers.

If this is deemed unsuitable for a field of its own, then 'enhancement' should
become a keyword, and probably so should 'inquiry'.  And probably also
'permanent', which would prevent a bug from being closed until it was
'de-permanented'.

(P.S.  Advocacy might qualify as an issue type, but it seems to work OK as a
component/product)

Comment 38

15 years ago
Hi,

does somebody modify patch v4 (12/18/01 15:10) for Bugzilla V 2.14.1 (or
2.15) ??

P.S. within 2 hours i could't find the downloadpage (or CVS tag) from
Bugzilla 2.15. Could somebody help me here ?
Daniel: 2.15 is "whatever's in cvs right now" so if you pull the tip, you have
2.15.  We tag an even-numbered minor version when we do an official release.

Comment 40

15 years ago
Created attachment 79233 [details] [diff] [review]
v5-post tempatisation update only
Attachment #61866 - Attachment is obsolete: true
Attachment #61936 - Attachment is obsolete: true
Attachment #61940 - Attachment is obsolete: true
Attachment #62141 - Attachment is obsolete: true
Can't this be done as part of the generic field stuff?

Comment 42

15 years ago
Some general comments from use on our installation, and Nathanael's concept:

1) checksetup.pl only adds the field, performing no data migration.  This leaves
all bugs with type=NULL.  Once a bug is then loaded, the list box automaticually
selects the first option, which in this case is DEFECT.  Some developers were
quite infuriated with this approach but no-one put up their hand to go thru and
classify every bug in the system.  The solution we came up with was to update
every bug to set the type to a new type 'BUG', allowing re-classification to 
occur over time.  This also required that new issues could not be created with
type  'BUG'.  We have since allowed issues to be added as type BUG, as it then
becomes an unclassified issue which an engineer needs to classify on behalf of
the reporter, as typically clients/functional experts will call enhancements
defects if given the chance.

2) Tracking bugs (aka META) do fit well within this change, however I see that
doing so is only an intermediate solution, as many tracking bugs are created due
to a lack of a better means of grouping issues.  keywords and type=FEATURE
should reduce the number of tracking bugs down to a set which could be addressed
in better ways (related issues, CRM, release management, etc).

3) The distiction between Feature and Enhancement is important, as the former
should extended with FeatureZilla (bug 75172), whereas an enhancement should be
linked to the feature(s) it enhances, thus keeping a high-level history of the
growth of a product/component.

4) Reminder / permanent task bugs do not seem natural.  Bugzilla is about
tracking development/work, not about storing process as a chain of id's.  If
these tasks are related to a milestone, each milestone should have a TASK
raised, with a URL to the process of releasing.  (... which, upon reading bug
4830, is exactly what has been suggested)

5) 'PATCH', as defined by IssueZilla, is quite unusual, however we have used it
(and from my experience on OpenOffice I suspect this is how Sun also use it) as
a porting/re-engineering issue type.  These issues can not be natually
classified as being or supporting a DEFECT/FEATURE/ENHANCEMENT.  The rationale
being that defects, features and enhancements end up on relnotes, whereas
patches are invisible to the client until a feature is considered which would
otherwise not have been contemplated by a manager.  These generally equate to an
engineer wasting time.  :)  Whether this is appropriate for b.m.o or the default
installation I can not say.

Comment 43

15 years ago
Using the generic fields enhancement (bug 91037) was discussed on IRC however I
have long forgotten the reason it was decided against, and so I fight on :). 
This is not about adding a field, but expanding Bugzilla itself to be less
defect-centric.  This deficiency has caused the project to be forked, and the
fork continues to live without improvements primarily because of this.   As
important as the distinction between defects and features/enhancements; the
distinction between tasks and defects/features/enhancements allows managers to
quantify the effort required to support a product.  Beyond that, if this
approach is not used, how will enhancements be classified on b.m.o in order to
solve this issue as per summary?  If everyone wants this, why make it custom?
Well, it would be a custom field restricted to a set of values, although I don't
know if that patch supports that.

It could be a custom field which is on by default in new installations.

Perhaps custom fields isn't the right name for it - I could easily imagine
severity + priority using that same patch.

enums are frowned upon, because they're mysql specific.
Created attachment 80410 [details] [diff] [review]
afranke's result of "cvs diff -u" inside the new template/en/default directory

This is what I got after migrating from my tree to the new template structure.
It's only templates. Before applying, you need to change to
template/en/default.
It touches the following files:

Index: bug/edit.html.tmpl
Index: bug/create/create.html.tmpl
Index: list/table.html.tmpl
Index: search/search.html.tmpl

Updated

15 years ago
Severity: major → enhancement
To those who were concerned about adding complexity to the bug form, I give you
this:

A "Record Classification" field (or whatever we call it) could potentially make
the bug form *more simple*, because some fields in the form may not apply to all
classifications, or may only apply to a specific classification, and by using
the classification field, only those fields which are appropriate to that
classification would get shown.

Zippy wants this, btw.
Blocks: 173124
Summary: Separate enhancements from severity field. → Separate enhancements from severity field / Bug classification field
Blocks: 65965
Define which fields ;) Woudl custfields then need to deal with that, too (ie
select on product, type) rather than just (product) ?
Actually, can't this just be done with custfields? Comment 43 says no, but the
attached patch definately can be done that way.

The m.o dependant bug could be done with a flag, instead - 'is-enhancement'

Comment 49

15 years ago
It looks to me like it could be resolved by custom fields.

However, I am not convinced that is the best solution.

There is the fundamental issue of classification which was addressed in
in comment 43, and reasons why having it are good for the Bugzilla as a whole.

I tend to agree with those comments, and think the native product should 
directly support the concept of classification of bugs.  I believe
using site-customized classifications would be a good idea as well.

Comment 50

14 years ago
*** Bug 202469 has been marked as a duplicate of this bug. ***

Comment 51

14 years ago
I would like to request that "requirement" be added as one of the classification
types.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22

Comment 53

13 years ago
Does anyone have the time/interest to update the patches and push this through
since there seems to be some interest in this sort of thing recently on webtools?

http://groups.google.com/groups?hl=en&lr=&frame=right&th=935f83eb8e16b470&seekm=mailman.1097025722.12833.mozilla-webtools%40mozilla.org#link2

Comment 54

13 years ago
I'll keep my eye on this, but I won't promise that I'll actually do anything,
certainly. :-)

By the way, these three categories actually cover what we need, in general:

Bug
Enhancement
Task

The difference between "enhancement" and "feature" is too confusing and likely
to shift around too much.
*** Bug 65965 has been marked as a duplicate of this bug. ***

Updated

13 years ago
No longer blocks: 65965

Updated

13 years ago
Blocks: 65929
Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.
Assignee: justdave → general
QA Contact: mattyt-bugzilla → default-qa

Comment 57

12 years ago
You know, this sounds like an ideal use of single-select custom fields.
Depends on: 287326

Comment 58

12 years ago
I'm really interested in such a feature. The attached patches a rather outdated.
Any updates on this?

Comment 59

12 years ago
Please see also bug 221017. It is a request for allowing cutom bug types with
custom create/edit/view templates.

Comment 60

12 years ago
The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).
Target Milestone: Bugzilla 2.22 → ---

Comment 61

11 years ago
I also like to see this field added, but it should be possible to edit/add the bug classe, so its not limited to the ones already mentioned. 

Maybe we could introduce an form distinction, so the admin can assign an own form template for each bug class. So it's possible to use simplified forms for certain classes. (this would be also useful to do it by product).

Comment 62

11 years ago
*** Bug 345169 has been marked as a duplicate of this bug. ***

Comment 63

11 years ago
Now that bug 287326 is completed, the question is if we want to ship "type" as a default custom field.

I'd say it's so common and useful that we should do it. I'd suggest these as types:

'Enhancement', 'Bug', 'Task', 'Tracker'

That would be the default list.
Assignee: general → create-and-change
Component: Bugzilla-General → Creating/Changing Bugs
Target Milestone: --- → Bugzilla 3.0
Version: unspecified → 2.10

Comment 64

11 years ago
We are freezing the code for 3.0 in two weeks and we don't expect this bug to be fixed on time.
Target Milestone: Bugzilla 3.0 → ---

Updated

11 years ago
Target Milestone: --- → Bugzilla 3.2

Updated

11 years ago
Whiteboard: [roadmap: 3.2] Comment 63

Updated

11 years ago
Duplicate of this bug: 369171

Comment 66

11 years ago
One the type should be "Issues" which can be matured to a 
  * Defect
  * Enhancement
  * Support (or educate user item)

Comment 67

11 years ago
Seems to me that (having read above) bug_type makes sense in many ways.  It gets rid of the severity issue, it helps users limit the type of issues they want to see (bugs vs enhancements vs support vs trackers ...), and it paves the way to display fields conditionally based on the type of issue being displayed.  It's difficult to compete with TeamTrack without these capabilities over the long-term.  I know - it's not feasible to implement today, but I think we ought to consider that for the future.

Updated

10 years ago
Duplicate of this bug: 75172

Comment 69

10 years ago
Now that we have custom fields, my company is going to add a "ticket_type" field to address enhancements plus ~7 other possible values.  

However, how would you upgrade older bugzilla databases?  Would checksetup.pl auto move all the enhancements to the new ticket type?  Would the bugs_activity database get updated as well?  

Comment 70

10 years ago
Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0

Comment 71

8 years ago
pyrzak's students' research pointed out that including "enhancement" in the Severity field makes enhancements seem less important than trivial bugs--a fact that does not actually match how the real world works.
Blocks: 490786
Priority: P3 → P1
Whiteboard: [roadmap: 3.2] Comment 63 → Comment 63

Comment 72

8 years ago
It also makes "minor" bugs seem less important than "normal" bugs, another fact that does not actually match how the real world works.  Severity should just die.
(In reply to comment #72)
> It also makes "minor" bugs seem less important than "normal" bugs, another fact
> that does not actually match how the real world works.  Severity should just
> die.

what would be the replacement for severity?  

Severity may not always, as you say, "bug A=severity major deserves more attention to bug B=severity minor".  But a) it is fairly well defined in that a) there is not much room for interpretation (something which has plagued STATUS=NEW for example), and b) isn't it a useful approximation, and at the least the best measure we have (until someone defines some alternative).

Comment 74

8 years ago
It doesn't need to be replaced.  It serves no purpose.  Nobody searches for sev:major bugs, or ignores a bug just because it is sev:minor.

For the clearest categories, severity duplicates information in the keyword field (crash, hang).  For the rest, everyone thinks their bug is "major".
(In reply to comment #74)
> It doesn't need to be replaced.  It serves no purpose.  Nobody searches for
> sev:major bugs, or ignores a bug just because it is sev:minor.

Most assuredly people DO use it to find, rank or ignore certain classes of bugs (including minor and trivial).  On the other hand, you are no doubt correct that some people never use it and don't need it.

Severity ...
* is easy for anyone to set accurately, even when not much accurate data is available
* the broad definition is exactly what makes it useful 
* helps in the allocation of scarce resources (people, time, etc)


> For the clearest categories, severity duplicates information in the keyword
> field (crash, hang). 

Yes, keyword adds clarity. But clarity does not by itself mean other information is duplication, nor useless, unless your only need/objective is to define issues in extremely narrow terms.  

> For the rest, everyone thinks their bug is "major".
true

If there is a broad problem with severity, perhaps it is more about  a) it may not be the right word,  b) other useful metrics are missing,  c) by definition it overlap other descriptors - priority (which has it's own problems because people haggle about a bug's priority as you point out above), keyword, etc.  Severity in IT is more often defined along the lines of http://www.redhat.com/support/policy/GSS_severity.html  

In an ideal world, with lush and copious keywords, fewer bugs, and better searching, you may be right. But right now about 75% of my searches use severity. two typical use cases
a) finding bugs of merit to bring them to dev attention
b) reducing a population of bugs from say 100 to 30 to more easily find dups or like bugs - because searching by summary and keyword, even with other criteria, frequently sucks

I suspect this discussion better deserves to happen in .quality or another bug.

Comment 76

8 years ago
(In reply to comment #74)
> It doesn't need to be replaced.  It serves no purpose.  Nobody searches for
> sev:major bugs, or ignores a bug just because it is sev:minor.

This assumption is wrong. I do search for bugs based on their severity, we don't release a new version when there are still bugs with severity blocker or critical, we prioritize patch reviews based on the severity of the bug, etc... So we definitely look at this field.

At least in the Bugzilla product, we don't let reporters set the priority. Module owners set this field.

Comment 77

8 years ago
(In reply to comment #72)
> Severity should just die.

  This is a discussion that belongs in another bug, for now.
Wow, so I didn't know there was so much discussion about this already. Let's vote for this bug with some reasonings/proposals/suggestions:

(In reply to comment #4)
> an enhancement is more of a bug classification type (crasher, enhancement, UI, 
> feature failure, documentation) than a severity. i'm wondering if it would make 
> sense to even take a stab at defining a classification type.

Agreed, but then how do we name each bugzilla entry? Still "bug"? An enhancement is not a bug. How about "ticket", as someone has already mentioned?


(In reply to comment #5)
> I'm not necesssarily disagreeing with the idea of classification types, but the
> things you mention here can already be supported as far as I can see.
> 
> crasher - bug, highest severity, possibly crasher keyword
> UI - component, or set of components, can have enhancements or bugs
> feature failure - a bug?
> documentation - a component as well, can have enhancements or bugs
(In reply to comment #37)
> * 'new feature' vs. 'feature enhancement' is extremely subjective; I'm not even
> sure how to tell the difference.
> * 'documentation' really belongs as a component.  It's not orthogonal to
> bug/enhancement/tracking.  Similarly for 'default configuration'.
> * 'hang' and 'crash' are always types of bugs (never enhancement requests), but
> might also be appropriate for tracking bugs.
> * 'performance' really could go on bugs, enhancement requests, tracking bugs,
> tasks, etc.
> * 'patch' belongs where it is: in the attachments field of a bug.  (Although
> possibly it would be nice to have multiple bugs be able to share an attachment
> easily.)  You can have patches for bugs, enhancement requests, tasks,
> inquiries,
> etc.

Agreed, let's not overpopulate the types. I liked this proposal from Max indeed:

(Quoting comment #63)
> I'd say it's so common and useful that we should do it. I'd suggest these as
> types:
> 
> 'Enhancement', 'Bug', 'Task', 'Tracker'
> 
> That would be the default list.

Yeah, but I would add one more and replace "bug" with another word. Why? Here are my reasonings:

a) I agree that the distinction between enhancement and feature is vague, however, during some years of software development now, I can state that sometimes the difference between "enhancement" and "bug" is *sometimes* also difficult to defend depending on the case, and it varies a lot depending on the point of view. For these type of cases, I would add a new item simply called "improvement". Also, this item would fit very well as a candidate for a default value, as in everything could be considered an improvement in the end. So I'm advocating for the same argument as this comment:

(In reply to comment #7)
> I like the idea of pulling enhancments out of the severity field.  However, I
> think that 'bug' is too overloaded, generic and even cute, so if we're going to
> use something to distinguish the default bug classification from enhancement
> requests, how about using 'defect'?  Are we going to leave it at two categories,
> or could we add other things the bug system is being used for, such as assigned
> tasks, programmer's notes to themselves, or what-have-you?


b) As some have already said, opening bugzilla to manage "tickets"/"issues"/whatever-term in a more general way, it broadly opens the door for its usage in much wider scenarios than only software (and this way we avoid common forks, right?). So now let's think of someone that is writing a book and sets up a Bugzilla instance to let the reviewers file "tickets" about it: wouldn't "defect" be a much better term than "bug" in this case? This way we're not software-centric, as this comment already points out:

(Quoting comment #9)
> Yes, one benefit of this being a classification type would be that you would
> not
> have to have a "bug" type, and would help Bugzilla to be used for other sorts
> of
> tasks that have nothing to do with software.
> 
> There are certainly other software oriented things hanging around of course, to
> fully fix this would require modularity (bug #13540).

So my proposal is:

"Bugzilla entry" -> "ticket"
"Types" -> 'Enhancement', 'Improvement' (default), 'Defect', 'Task', 'Tracker'

Now let's think about this addition that is very interesting as well IMO:

(In reply to comment #66)
> One the type should be "Issues" which can be matured to a 
>   * Defect
>   * Enhancement
>   * Support (or educate user item)

Support? Mmmm, well, if I'm thinking the same as you're thinking, that's not a bug type, but it can be either:
- A resolution status (sometimes if a user doesn't understand a feature, she thinks it's a bug, but then she gets educated as soon as INVALID or WORKSFORME statuses are issued).
- A defect, but on a different component (documentation, for instance). And I've seen a lot of cases in which an INVALID status changes to REOPEN at the same time as the component is changed to DOCS in this sense.

Another one I'd like to refuse is:
(In reply to comment #42)
> 5) 'PATCH', as defined by IssueZilla, is quite unusual, however we have used it
> (and from my experience on OpenOffice I suspect this is how Sun also use it) as
> a porting/re-engineering issue type.  These issues can not be natually
> classified as being or supporting a DEFECT/FEATURE/ENHANCEMENT.  The rationale
> being that defects, features and enhancements end up on relnotes, whereas
> patches are invisible to the client until a feature is considered which would
> otherwise not have been contemplated by a manager.  These generally equate to an
> engineer wasting time.  :)  Whether this is appropriate for b.m.o or the default
> installation I can not say.

A patch has always a cause in the end, and that underlying cause is indeed the type of the bug. Even in the most weird in case in which you may think there's no real "cause" because it's a change needed as a dependency of another thing (a "refactoring") we could always mark it as "Task" simply.

And last one I don't agree with either:

(In reply to comment #51)
> I would like to request that "requirement" be added as one of the
> classification
> types.

But everything is a requirement! A bug to be fixed, a feature to be created, a task to be done... I guess you're advocating for "requirement" instead of "ticket" for the "bugzilla entry" word :)


In regards to "severity should die", I agree with:

(In reply to comment #76)
> At least in the Bugzilla product, we don't let reporters set the priority.
> Module owners set this field.

Also because there can be a high sev but low priority bug (because let's say it happens one time every 10.000.000 cases...)

(In reply to comment #77)
>   This is a discussion that belongs in another bug, for now.

Right, so I'll shut up.

Thanks!
In case someone really cares about my last huge comment... Just wanted to point out 2 typos:

(In reply to comment #78)
> ...
> So I'm
> advocating for the same argument as this comment:
> 
> (In reply to comment #7)
> > I like the idea of pulling enhancments out of the severity field.  However, I
> > think that 'bug' is too overloaded, generic and even cute, so if we're going to
> > use something to distinguish the default bug classification from enhancement
> > requests, how about using 'defect'?  Are we going to leave it at two categories,
> > or could we add other things the bug system is being used for, such as assigned
> > tasks, programmer's notes to themselves, or what-have-you?
> 

This was indeed relevant for the (b) element, not (a).

> ...
> Also because there can be a high sev but low priority bug (because let's say it
> happens one time every 10.000.000 cases...)

With high sev I meant something like a crasher.


Just my 2 c. Keep up the good work on bugzilla!

Comment 80

8 years ago
Hey Andres. Thanks for all your feedback. I don't have the time at the moment to respond to everything you said, but I do want to mention that our focus is primarily on software bug-tracking. I would actually rather that people fork and customize if they want to do other things that don't fit within that model. If people feel that the software bug-tracking model is good for hardware bug-tracking, then that's great. If they feel that the model is also good for ticket tracking, then that's great. But we can't let the scope creep for our already extremely-convolution system any more than it already has, so I have to say that our primary focus will remain software bug tracking, and not general task tracking.

Comment 81

8 years ago
I have been using custom fields for a year or two now in order to accomplish this:
1. Create a custom field "Type" with values:
1.a. Defect - bug in existing functionality
1.b. Enhancement - non-bug requested modification to existing functionality
1.c. Estimate - provide an estimate for the amount of work to do something (which may or may not be done)
1.d. Feature - entirely new functionality
1.e. Question - work item that is not requiring any code changes yet requires developer involvement to come up with a solution
1.f. Meta - not an issue (usually some sort of tracker)
1.g. Report - for one-time reports generated by developers
1.h. Task - a component work item of a larger Defect/Enhancement/Feature/...

2. move all Severity=Enhancement bugs to Severity=Normal, Type=Enhancement or Type=Feature

3. delete Enhancement severity

Some of these types are likely unnecessary for certain installations. This method has actually worked out very well and I think this might actually be the best way to do this.

Comment 82

8 years ago
Hi All,

(In reply to comment #80)
> Hey Andres. Thanks for all your feedback. I don't have the time at the moment
> to respond to everything you said, but I do want to mention that our focus is
> primarily on software bug-tracking. I would actually rather that people fork
> and customize if they want to do other things that don't fit within that model.

Max, I agree with you, bugzilla is very good at tracking sofware issues but it might good to look twice at this request.
First of all the bug number itself indicates that the need is really there for a long time, and the number of comments confirms that no proper solution has been found.
Most of bugzilla installation have been tweaked to track more than just software bugs, even b.m.o is tracking more than just "software bugs"...

On my installation, I have renamed "bug" to "ticket" and I am using the severity field to classify the ticket:
- Defect-Blocker (for internal usage: blocking development)
- Defect-Critical / Defect-Major / Defect-Normal / Defect-Minor / Defect-Trivial
- Enhancement
- Task (for internal task, such as planning / retrospectives)

It works fine, but it's still not perfect, and not straight-forward for "external" people, not used to the system.

I had a look at http://jazz.net/ , the IBM solution for collaborative ALM, and I found their "work item" idea really neat. A "work item" can be anything from "defect" to "plan item".

Having said that, I take to opportunity to thank everyone for the job done.
Congrats guys!

Comment 83

7 years ago
I'd like to quote a post regardnig Mozilla calendar development:
http://weblogs.mozillazine.org/calendar/2010/03/reducing_the_calendar_bug_coun.html

"It's important to note that not every bug in our database is a real program error. Our bug list also contains lot of enhancement request, project management issues and enhancement requests. Basically everything that comes up in our project that needs to be tracked somehow is entered in our bug database, so that it can be easily tracked."

If the author needs to clarify the situation, I think there is a space for improvement on bugzilla UI.

I initally mentioned my experience while here we can see that people contributing to Mozilla's project might be confused as well.

I'd like to hear from other large project contributors as well, how they overcome (or not) this limitation of bugzilla.

Have a good day

Comment 84

5 years ago
We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.
Target Milestone: Bugzilla 4.4 → ---

Comment 85

4 years ago
btw: i`m using keyword for distinguishing between bugs and requirements. the only problem is to say that 'keyword is mandatory'.
but it allows me to mark items as 'bug', 'requirement' or even 'bug, requirement' sometimes

Comment 86

4 years ago
First... I chcuckled at seeing so many people trying to define and redefine categories and terminology exactly as we have here for at least a decade :)
Second, even though this may never get seen my 2 cents:
We now consider every issue to be a 'bug'. A bug is something that a user encounters which does not provide an expected result. Such as a 'missing' report or missing columns on an existing report. A bug either has explicit or IMplicit Business Requirements which have been violated either in reality or by not being present anywhere in the documentation. 

To put it as simply as I can: A bug is a behavior of a system which does not  fulfill business requirements. Period. Either code to the existing requirements or gather new requirements. It is all the same. really :)

Comment 87

4 years ago
(In reply to Rick from comment #86)
> We now consider every issue to be a 'bug'.

and 

> A bug is something that a user encounters which does 
> not provide an expected result.

Either there is a contradiction there, or you track way less stuff in your Bugzilla than we do.  For example, we track invoicing, requirements gathering, procurement, research, marketing, training, etc. in our Bugzilla, none of which are things that "a user encounters which does not provide an expected result", but all of which are "bugs", i.e. things that need tracking by Bugzilla.

Therefore, a customisable bug category field would be massively useful for us - currently we are working round the limitations and to not have to do so would make it a whole load easier to use and a whole load simpler to teach to new employees.  

We have recently upgraded (finally!), so possibly a custom field is sufficient to resolve this issue (as per comment 80) - I will investigate.

But regardless of that, Bugzilla should probably offer this out of the box (even if it is just a custom field that ships with the software, which can be edited/removed by the user) as the current situation where 'enhancement' is grouped in with the severities is just confusing (and, from my experience, not just to new users).
You need to log in before you can comment on or make changes to this bug.