65558 - codelevel keyword

Status: RESOLVED WONTFIX

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

Description

[Andreas Franke (gone)]

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

Comment 1

[lchiang]

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?

Comment 2

[chris hofmann]

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.

Comment 3

[Andreas Franke (gone)]

Chris:

[in reverse order, sorry]:
> if it's 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.

That's a good point. But I never suggested something like this. The bugs I'm
talking about just do not intend to directly fix a problem that can be observed
by a user (unless she has turned on special debug options, or runs in a
debugger,...). That doesn't imply that these bugs are not important, or that
fixing them they can't cause regressions. I assume that many of these bugs are
even blocking some very visible, important bugs and features.

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

Agreed. But this only means that in most cases there should still be a QA
contact for these bugs, and the verification consists of triggering the code in
question and making sure that it still behaves the same way as before. 

> the term "code level" has never made any sense to me.

Well, what about "unobservable-by-non-debugging-users" instead? If you like, you
can exchange it with a set of more specialized markers that together make up for
this.

Lisa:

> What would be the use of such a keyword?  Is there a specific need for that?

This could be a step towards a "bug type classification" system made of
keywords. I'm going to describe the idea in bug 63351 in a minute.

Besides that, it could help improving statistics (not by just excluding these
bugs from queries, but by charting them separately). I don't know much about the
recent trend in bug numbers since bug charting is still broken (see bug 6682),
but I assume filing 90 "Javascript strict warnings in XXX" bugs _did_ have an
influence. (The following is oversimplified, but:) As opposed to ordinary bugs,
the general rule here is "the more, the better" because filing such a bug is a
constructive act that helps in getting things fixed, improving the source, and
giving an insight to the outer world about what's going on, and how it's done.
Many concrete, small bugs of this kind are better than a single vague, big one.

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

If all bugs in a component fall in this category, then there wouldn't be a need
for it, since queries can work around this by including or excluding all bugs in
that component. But if you see it as part of a "bug type" classification
mechanism, then each and every bug should probably have at least one of the
classifying keywords, including those in a component where one category
dominates.

Comment 4

[lchiang]

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.  

Comment 5

[Andreas Franke (gone)]

See also: 
bug 67635 which suggests a (code-)"readability" keyword (similar to this one)
bug 70749 which suggests a "visible" keyword (pretty much the opposite)
bug 65965 for the "bug type classification"

Comment 6

[ratman]

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.

Comment 7

[timeless]

I don't see a use for this.  There's a documentation component and there are
other ways...

Comment 8

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

Comment 9

[Andreas Franke (gone)]

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.

Comment 10

[Andreas Franke (gone)]

I should say that personally I prefer "code" over "readability" for this
purpose.