65965 - Bug type classification (based on keywords?)

Status: VERIFIED DUPLICATE of bug 9412

(bugzilla.mozilla.org :: General, enhancement)

Description

[Andreas Franke (gone)]

Divide and Conquer...

Brendan wrote in the roadmap: "Mozilla needs performance, stability, and
correctness" and not any particular new feature. This can be seen as the
beginning of a bug type classification. Currently there is no "Bug Type" field
in bugzilla, but there are already keywords that cover parts of it:

- performance: perf, footprint, mlk
- stability: crash, hang
- correctness: correctness, or there could be used fine grained keywords like 
               css1, css2, css3, css-moz etc., see Hixie's 2000-12-22 21:06 
               comment in bug 63351 (which asks for removal of `correctness' kw)
             
New features have severity="enhancement" set, that's a bit different, but it's
still something you can query for. And then there are `arch' and `embed'
keywords which can be seen as "bug types", too. 

This raises the following questions: What other bugs are there in Bugzilla? Can
they all be classified? Would it help anybody if we managed to set up such a
classification system, e.g. define a list of bugs and try to set up a rule that
every bug in a given set of products should have at least one such keyword?

My guess is that it _would_ help. If everybody was asked to add one of the
classification keywords to bugs at the time they are filed, the "only one bug
per report" problem would be avoided automatically, and hopefully some report
would be more focused because the reporter would have to think about the nature
of his bug when filing it.

Alternatively, an additional select box could be added to Bugzilla to store this
information. But I think keywords are better suited for this purpose because
they are already in use for some of the most important types (they smoothly
integrate with the current system), and in particular they don't need anything
changed in Bugzilla. All one would have to do is define a set of keywords as
"bug types" and ask everybody to try to add at least one of these keywords to
every bug.

One possible keyword I thought of as missing was `codelevel' (for things like
code cleanup; I don't consider `polish' a good name for a bug type), but that
probably isn't a good solution, see bug 65558.

Comment 1

[Andreas Franke (gone)]

Since this would hopefully make bugs easier to find, I'm making meta-bug 65929
dependent on this one.

Comment 2

[lchiang]

If the consensus is to do this and use keywords, the following would need to be
changed:  Keywords should be available when a bug is first entered.  Otherwise,
it will not be used as much.

Also, I worry about the size of the keyword list - the list encompasses keywords
besides those having to do with bug classifications that it will be hard to know
which keywords are classifications without perusing the entire list.

Regardless, here are comments on types of bugs:
1.  many types of UI bugs (ie.  The menu item does not match the spec, The
toolbar button is chopped off, etc).  Do these fall under "correctness"?
2.  It may be a useful exercise to take a random sampling of bugs in all
product/components (not just browser :-) ) and try to see what bug class they
would fall under so that the choices we come up with are representative of all
areas of Mozilla.

Also, I don't think "embed" is a type of bug.  Embed is an area where a bug occurs.

Comment 3

[Andreas Franke (gone)]

[For some reason I did not receive mail with the last comment (yet).]

I'm changing the summary to reflect keywords are only one possibility to
implement a bug type classification system in Bugzilla, and I don't think we
need separate bugs (yet) for alternative approaches.

Just that this idea doesn't get lost: If we choose to use a select box for this
purpose, I believe morphing the Version field into a Bug Type field (by just
renaming it) would be easy and give us exactly what we want. That field
currently isn't used much, and using it for bug type classification (instead of
removing it) would help us a lot more. It's already present in the database, on
the bug entry form, on the query form, and I think allowing a different value
set for each product makes perfect sense. 

The "Documentation" product could be used to try out a bug type classification
system. There are currently about 60 open bugs, and I think the following value
set would cover many of those bugs:
- new/missing doc: requesting a new document to be created
- rewrite/outdated: requesting an existing document to be replaced
- error/change: requesting a specific change/correction/update to a document
- publishing/availability: issues related to availability etc.

For the mozilla.org product, a bug type "process/system change" ("reform") would
be needed.

"Keyword field in new bug entry" is bug 25521. Adding dependency for now.

The size of the keyword list is not a critical issue. If you are worried by the
length of the keyword list, then the root cause should be addressed: It should
be replaced by 
1. a lookup tool for existing keywords: type a keyword and get its definition
2. a search tool for keyword descriptions: you type in some words or word
fragments, and all matching keyword definitions are shown, _and_ 
3. a listing of keyword groups (=keyword types ;), e.g bug type, distribution,
schedule, etc., with links to pages with the respective keyword descriptions
that belong to that group.

If you ask me, there are several types of UI bugs, e.g.
- doesn't match the (publicly available!) spec: if the spec is cited, that could
fall under correctness (or there could be a separate keyword for it)
- display/presentation errors: something is chopped off, invisible, garbage is
shown, clearly appears at the wrong place, has the wrong colour, is not
disabled, ... these would also be correctness if we didn't have anything else,
but in my view that's a different category
- usability issues
But I'm not a UI expert, so I would leave that classification to the more
knowledgeable.

The random sampling is a good idea, but maybe it should be several samplings for
different products. "Documentation" and "mozilla.org" probably both have
different bug types than ``software'' products.

Anyway, if more people think that having a bug classification by type would be
beneficial, this should run through the newsgroups first.

Comment 4

[Andreas Franke (gone)]

What's the next step here? If we need some random bugs, here is a URL of
generated from some random numbers smaller than 65000:

http://bugzilla.mozilla.org/buglist.cgi?bug_id=9993,64844,7028,25614,5647,54477,62406,25536,36351,18786,27840,45314,26527,32891,27401,50628,40964,32165,123,5648,56771,62790,10389,21577,39765,49954,6824,54710,44848,27521,51333,54841,13717,58362,1807,19364,34191,64214,31253,5542,4352,59093,37208,30879,26984,64609,2859,2948,31774,54335,8596,9898,52125,5337,31475,13242,55292,24651,2952,21492,38524,40638,62685,52241,34000,64492,57958,54543,50058,24211,60085,40762,18304,32293,57993,45288,18255,47205,34589,36381,36540,43185,46279,10017,34875,64107,23260,25167,23758,12564,33011,62283,53202,17048,35876,8554,16540,28834,63097,52951

77 of them are Browser bugs:
http://bugzilla.mozilla.org/buglist.cgi?bugidtype=include&bug_id=9993%2C64844%2C7028%2C25614%2C5647%2C54477%2C62406%2C25536%2C36351%2C18786%2C27840%2C45314%2C26527%2C32891%2C27401%2C50628%2C40964%2C32165%2C123%2C5648%2C56771%2C62790%2C10389%2C21577%2C39765%2C49954%2C6824%2C54710%2C44848%2C27521%2C51333%2C54841%2C13717%2C58362%2C1807%2C19364%2C34191%2C64214%2C31253%2C5542%2C4352%2C59093%2C37208%2C30879%2C26984%2C64609%2C2859%2C2948%2C31774%2C54335%2C8596%2C9898%2C52125%2C5337%2C31475%2C13242%2C55292%2C24651%2C2952%2C21492%2C38524%2C40638%2C62685%2C52241%2C34000%2C64492%2C57958%2C54543%2C50058%2C24211%2C60085%2C40762%2C18304%2C32293%2C57993%2C45288%2C18255%2C47205%2C34589%2C36381%2C36540%2C43185%2C46279%2C10017%2C34875%2C64107%2C23260%2C25167%2C23758%2C12564%2C33011%2C62283%2C53202%2C17048%2C35876%2C8554%2C16540%2C28834%2C63097%2C52951&product=Browser

19 of them are MailNews bugs:
http://bugzilla.mozilla.org/buglist.cgi?bugidtype=include&bug_id=9993%2C64844%2C7028%2C25614%2C5647%2C54477%2C62406%2C25536%2C36351%2C18786%2C27840%2C45314%2C26527%2C32891%2C27401%2C50628%2C40964%2C32165%2C123%2C5648%2C56771%2C62790%2C10389%2C21577%2C39765%2C49954%2C6824%2C54710%2C44848%2C27521%2C51333%2C54841%2C13717%2C58362%2C1807%2C19364%2C34191%2C64214%2C31253%2C5542%2C4352%2C59093%2C37208%2C30879%2C26984%2C64609%2C2859%2C2948%2C31774%2C54335%2C8596%2C9898%2C52125%2C5337%2C31475%2C13242%2C55292%2C24651%2C2952%2C21492%2C38524%2C40638%2C62685%2C52241%2C34000%2C64492%2C57958%2C54543%2C50058%2C24211%2C60085%2C40762%2C18304%2C32293%2C57993%2C45288%2C18255%2C47205%2C34589%2C36381%2C36540%2C43185%2C46279%2C10017%2C34875%2C64107%2C23260%2C25167%2C23758%2C12564%2C33011%2C62283%2C53202%2C17048%2C35876%2C8554%2C16540%2C28834%2C63097%2C52951&product=MailNews

1 PerLDAP:        http://bugzilla.mozilla.org/show_bug.cgi?id=8596
1 MozillaClassic: http://bugzilla.mozilla.org/show_bug.cgi?id=123

Should this be used as a representative sample?

Comment 5

[Stuart Donaldson]

The type classification should be something that can be applied on a product by
product basis, and should be applied thourgh a selection box rather than
requiring someone to type in a keyword they have to either remember, or lookup.

Something along the lines of the category field, or the version field as was
suggested would be a good way to do it.

However in my case, using bugzilla for other projects than mozilla, I use
version, product, and milestone already.  So adding a new field would be much
more useful for me trying to morph one of those fields.

Comment 6

[Andreas Franke (gone)]

See also how http://www.mozilla.org/roadmap/mozilla-1.0.html uses the existing
keywords for a categorization.

Comment 7

[Hixie (not reading bugmail)]

->me

Comment 8

[Hixie (not reading bugmail)]

This is all very well but what is it asking for?

INVALID based on the fact that there is nothing to fix here.

Comment 9

[Daniel Veditz [:dveditz]]

Reopening, sounds like a clear request to me: Steal the existing unused version
field (or create a new field) and have a per-product drop-down for bug-report
classification. For development products (Browser, mailnews) this could be
 - Defect
 - New feature
 - Meta (or "tracking", "project" or whatever)

Examples for the documentation product given in comment 3

Comment 10

[Stuart Donaldson]

I agree that this is a request for a new feature to provide a 
classification system. The "(based on keywords?)" in the summary is simply an
example of how it might be provided.

I think this bug could be resolved by incorporating:
bug 91037 a generic implementation for custom fields.

Having custom fields would allow definition of a Classification field.  However
since custom fields will likely always have a performance penalty, I would opt
for a site-configurable classification system for bugs.

Comment 11

[Hixie (not reading bugmail)]

For "feature" we have "Severity: Enhancement".
For "meta" we have the "meta" keyword and the "Tracking" component.
For "defect" we simply have the lack of any marker to the contrary.

Why do we need any more? I don't want to add something which is only used by 10%
of the bugs, since that would only result in people quoting misleading statistics.
What's the actual use case for this?

Comment 12

[Stuart Donaldson]

Placing "Enhancement" in severity is a kluge.

Severity describes the "impact" of the bug, and a trivial/minor/major/critical
are all easily understandable as related to a bugs impact.

However "enhancement" is not an impact issue.  You could have an enhancement
that has a trivial impact, as well as one that has a major impact.

Comment 13

[Dave Miller [:justdave]]

See bug 9412.  I don't think mozilla.org can implement what you're asking for
without support from the Bugzilla application (thus the dependency I just set).

Let this bug sit until the dependency is resolved, and go take your comments to
bug 9412 where it might do some good. :)

Comment 14

[Hixie (not reading bugmail)]

If there isn't anything that can be done here, I'd like to take this bug off my
radar (i.e. resolve it). Are there any objections?

Comment 15

[Daniel Veditz [:dveditz]]

yes, I object. If you want it off your radar why did you assign it to yourself?

Comment 16

[Hixie (not reading bugmail)]

...because I'm the guy in charge of component and keyword changes now.

Oh well. Since you want to keep it open, let's keep it open. I'm not sure I see
the point, but...

Comment 17

[Hixie (not reading bugmail)]

->dveditz since he wants it open and I don't want it on my radar

Comment 18

[Dave Miller [:justdave]]

dveditz: you still want this bug around?  I think it's pretty much a dupe of bug
9412.

Comment 19

[Daniel Veditz [:dveditz]]

*** This bug has been marked as a duplicate of 9412 ***