There is a class of bugs that aren't visible to any user. There should be a way to exclude these bugs from queries. One step in this direction might be the introduction of a "codelevel", "codeonly" or "srconly" keyword. This could be applied to bugs like "eliminate NS_COMFALSE" and probably also "Review new DOM APIs" and "JS strict warnings in ...".
What would be the use of such a keyword? Is there a specific need for that? There are some components where it's by default that the bugs are code-level only. Would these bugs all need to have this keyword placed on them?
the term "code level" has never made any sense to me. all the code we have that executes in the product should be doing something on behalf of a direct user action or on behalf of something we do "automatically" for them. true, that some code, api levels, or bookkeeping functions are lower level than others, but that doesn't mean they can't be, or shouldn't be, translated into something that the user does or the program does automatically on their behalf... When 'code level' changes are made they can be just as important and big as source of regressions as changes that are directly visable to users. I think its a mistake to have this keyword; espcially if its used as an excuse to not think about or evaluate what types of test case need to be executed to regress certain types of code changes.
I'm sorry, but I don't see a need to track bugs at this level for stats. I still don't understand why we need to track to this level. A bug at a code level (ie. not exposed in the UI) should still be prioritized along similar severity/priority with bugs affecting the UI. However, your idea of classifications of bugs is a good one. It used to be that we used "severity" to classify types of bugs (ie. causes crash, misspellings, etc), but I guess that the definitions have gotten too vague over the years. I just think that it is a lot more work to put bugs into classes unless the classifications really help to make our jobs easier and provide meaningful data that can be applied towards something. I'm not saying that Mozilla can't have this if that's what the Mozilla community wants. I'm just not an advocate for having this keyword.
a quick note on bug 70749 - it's basically the reverse case, using a "visible" keyword instead of a "non-visible". it's a keyword mostly for people who may operate on a more user-based level in terms of their interest in mozilla, or for people who wish to follow and observe the bugs that users are most likely to see and complain about. administrators who are less interested in perf or dom issues and more interested in a worry-free browser would find this type of keyword more useful than what's available right now. this would also assist in screening out "codeonly" bugs in queries. choosing between a "codeonly" or a "visible" keyword is a matter of semantics, but it does have a clear and practical application beyond statistics. okay, so that wasn't such a quick note after all.
I don't see a use for this. There's a documentation component and there are other ways...
QA Contact: lchiang → timeless
i think we might fix bug 67635 so i'm going to wontfix this, that bug's keyword suggestion and text are both clearer.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
Ok. But please don't verify this until there are other means to exclude code-only bugs from queries, so that the default query for new users can hide these bugs. Until then, this is a valid enhancement request.
I should say that personally I prefer "code" over "readability" for this purpose.
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.