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.

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.

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 .)

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.

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.

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.

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).

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.

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.

mpt, are you saying we should nuke enhancement altogether?

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.

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.

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

moving to real milestones...

*** Bug 71446 has been marked as a duplicate of this bug. ***

Taking all of cyeh's Bugzilla bugs.

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.

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.

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.

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...

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

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 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.

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>

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.

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)

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.

Can't this be done as part of the generic field stuff?

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.

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.

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

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.

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'

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.

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

I would like to request that "requirement" be added as one of the classification types.

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.

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

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. ***

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.

You know, this sounds like an ideal use of single-select custom fields.

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

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

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).

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).

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

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.

We are freezing the code for 3.0 in two weeks and we don't expect this bug to be fixed on time.

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

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.

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?

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.

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.

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).

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.

(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.

(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!

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.

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.

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!

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

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.

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

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 :)

(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).