Closed Bug 63351 Opened 25 years ago Closed 25 years ago

Remove `correctness' keyword

Categories

(bugzilla.mozilla.org :: Administration, task)

Product:
bugzilla.mozilla.org
Component:
Administration
Type:
task
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: asa)

Details

The `correctness' keyword should be removed. Reasons: * Currently on 1141 bugs, this keyword is clearly being abused: it has no real purpose or meaning, and as it's currently described, any real bug could fall under it (since a bug, by definition, is when the correct/expected behavior does not occur). There is no real correlation between all the bugs that use this keyword. * No apparent usefulness. How often does the need for this arise?
adding a few of the people who have been using this keyword recently.
My (perhaps uninformed) understanding of this keyword is that it is useful to flag standards compliance bugs -- i.e. where "correct behavior" is defined by an outside entity such as a standards document. I think it is important to have some keyword to flag this kind of bug, and I don't mind abandoning "correctness" if it is replaced with something more precisely defined. How about using "compliance" for this purpose. If the reporter is correct that "correctness" is being abused and has become meaningless, then I guess it should be changed to be more clear. If the keyword is removed, I hope someone will do a bulk update to bugzilla to send out e-mails for all relevant bugs, and will notify interested parties about thenew standards compliance keyword, whatever that is.
David, we have a variety of keywords for standards compliance, each representing the various languages (e.g. css2, html4, XHTML, etc.). If we don't have keywords for certain languages, and there's enough demand for them, we can add them.
As far as I can see from the keywords list, there are no keywords specific to the DOM or ECMAScript standards, which is where I've been reporting bugs, which is why I've been using "correctness". Granted, the Component: field categorizes these types of bugs, but I think there ought to be a keyword to specify that a bug is a standards-compliance bug as opposed to, say, a performance bug. I still think a generic "compliance" keyword is better than adding a new keyword each time a new standard is promulgated.
See also bug # 58124, in which I propose adding a new severity level of "non-conformant". I still like this idea, even more than adding a new "compliance" keyword. Brendan Eich doesn't like the idea, however, and he's certainly got more experience than I in these matters.
i have no problem with it going. However, some people might want a keyword for bugs that bream certain standards, like the w3c and friends. So we should ask them (hixie is the ns Stanadards QA, so his input is really needed).
JS errors -> JS Engine component CSS errors -> css1, css2, css3, css-moz keywords DOM errors -> relevant DOM component PNG errors -> PNG component RDF errors -> RDF component SVG errors -> SVG component XBL errors -> XBL component XML errors -> XML component XUL errors -> XUL component HTML errors -> dependency on 7954 HTTP errors -> no clear marker XSLT errors -> XSLT component XHTML errors -> xhtml keyword MathML errors -> MathML component RFC822 errors -> no clear marker Performance issues -> perf keyword Memory Leak issues -> mlk keyword Architecture issues -> arch keyword Minor Polish issues -> polish keyword Why do we need 'compliance'? Does it help anyone?
Currently we don't have a keyword or a component for UI correctness. Read the keywords and component descriptions before telling me that we have 'ui' and 'softui' neither of which relate to platform ui. Nor does B[UI:DF] nor B[XP T/W*] Using correctness in that sense means that a widget should behave correctly (and does not currently) according to the platform, it however is _not_ a compliance issue.
That one person thinks this is a standards compliance keyword and another thinks it's for UI spec correctness is exactly the reason that this keyword needs to be removed -- it's too broad and too general, and being used for too many different purposes.
Let's remove qawanted and crash too. qawanted has all sorts of uses. Crash can mean system crash, system killed app, plugin killed app, power killed system... </sarcasm> qawanted usually includes a status whiteboard message explaining what qa is needed. correctness is usually specified by category or whiteboard.
Not at all, and you know it. Keywords are to keep track of a specific class of bugs. If I'm looking for crashing bugs, the `crash' keyword will give me a list of crashers, regardless of the cause of the crash. The same holds true for qawanted. People define correctness in different ways. > correctness is usually specified by category or whiteboard. Really? Do you actually know this, or are you just saying it? I looked through a whole bunch of bugs with the correctness keyword and didn't see any kind of clarification in the status whiteboard (but it's a moot point -- the status whiteboard is a place for status, not for clarifying the intent of a keyword).
At a minimum the definition needs to be updated. Without an update to the definition this keyword might as well be "bug". So far the only thing that I'm seeing isn't already covered is timeless' "OS UI conformance/correctness" issue. Should this keyword be updated to flag that class of bugs (are there enough of them to warrent a keyword)?
No, I don't think this keyword should be morphed into UI correctness and spec conformance, and I point to the `mailspecui' keyword as evidence that there's little demand for such a keyword. This keyword is expressly for that purpose, and currently isn't used anywhere. And for good reason. Sure, we can probably think of hundreds of ways to classify all the bugs in the database; but keywords should be about demand. How often are people needing to keep track of everywhere in the product that the UI doesn't match the spec? Even if there was demand for it (and `mailspecui' seems to suggest otherwise), there are likely few people who care about inconformance in all areas of the product. Another question: against what "official" Mozilla specs is "correctness" based? I wasn't aware that any existed. Let's please stop creating new keywords and bug classifications until there is perceived demand for them. This is how our current keyword list got as long and polluted as it is now.
Hixie: I think components alone are not sufficient to distinguish correctness/compliance bugs ("current behaviour clearly violates an existing spec") from others (stability, performance, architecture, usability, ...). See e.g. bug 63335 (SVG), bug 40757 (Javascript Engine), bug 10410 (XML),... If you ask me, having a "bug type classification" system (see bug 65965) _is_ likely to help because people would be forced to think about what a bug is really about at the time they file it. This doesn't mean I insist on having a "correctness" keyword. E.g. there are `crash' and `hang' keywords instead of a global `stability' keyword. Correctness bugs could be handled the same way: One keyword for each specification (or group of specs) that mozilla is trying to support, like css1, css2, css3, ... Alternatively, if a selectbox (like the current "Version" field) is used to represent the bug type in Bugzilla, "correctness" could be used there.
Status: NEW → ASSIGNED
OK, I read more than half of the 276 bugs which have ever had _only_ this keyword added (as an experiment) and I cannot find any unifying factor except that they were all filed in Bugzilla. There were bugs on buttons not working right, on dialogs the wrong size, on performance problems, on standards support on missing 4.x features, on crashes, etc. I'm going to be killing this keyword shortly unless someone else reads more than I did and can enlighten me with the thread that all these bugs have in common. We do have DOM and CSS keywords and I'll consider others but this keyword is not slavageable. Kinda funny that even though the definition explicitely says "though not a crash" there are 22 bugs that have both correctness and crash keywords.
Asa, since you have read a lot of bugs, can you suggest a set of categories that could replace the "correctness" category in a hypothetical "bug type classification" system? Using correctness together with crash is bad keyword usage because they are mutually exclusive, and a "bug type classification" system would ensure that there a bug only belongs to one of these categories at a time. The same applies to standards compliance keywords. If there are already specific keywords to track these kinds of bugs, one could set up a rule that their use excludes the use of "correctness". > I'm going to be killing this keyword shortly Ok. Are there already existing categories so that each of the bugs you read would fit in exactly one of them? Or which new ones do you suggest? Blake wrote: > Let's please stop creating new [...] bug classifications until there is > perceived demand for them. There is demand. With such a system, if it is well-designed, looking for bugs will be much easier, leading to less duplicates. It will help the project in the long run because the understanding of how bugs are distributed in bugzilla will be better. Also, it may help motivation by allowing for better statistics. Example: if you can show that the number of correctness bugs is decreasing fast, then an exploding number of incoming bugs won't make you cry, as long as they are all just minor usability enhancement requests. If you still don't believe me, then here's another point: Others do it, too. See e.g. http://gcc.gnu.org/gnats.html , they have some "Class"es there.
Keywords for classification are largely useless because they are massively underused. I would guess there are twice as many CSS bugs without the CSS keywords are there are _with_ the CSS keywords, for example.
I think this keyword can be removed. I think most of the bugs in bugzilla are some form of correctness bug. Correctness is too broad.
fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
vrfy keyword removed
Status: RESOLVED → VERIFIED
QA Contact: lchiang → timeless
Component: Bugzilla: Keywords & Components → Administration
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.