66084 - (Query based) Partial Bugzilla Index by UI Element Names

Status: RESOLVED INVALID

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

Description

[Andreas Franke (gone)]

It would make bugs in Bugzilla much easier to find if there was an index. Since
no one knows how to generate a good index automatically, it would have to be
created manually.

* One possibility for such an index would be something like dmoz.org for
Bugzilla. But probably that's not worth the effort, especially since Bugzilla
content is changing rapidly as bugs are resolved and new ones filed.

* There already _exists_ an index for Bugzilla: Product & Component. But since
some components have more than 500 open bugs (e.g. Layout), this is not really
sufficient. Having finer grained components would be helpful, but that would
require component _trees_ to be supported by Bugzilla (bug 43940), and that
probably won't happen soon. (Feel free to prove me wrong. :)

Now what I propose in this bug is something that requires much less work than a
full, manually maintained index, and on the other hand may prove even more
useful than component trees:

* Take a screenshot of a full browser window and annotate each UI element with
its "official" name. Clicking on that "official" name should open a small page
that contains:
1. the "official" name again
2. synonyms used in Bugzilla
3. relevant Bugzilla components
4. a Bugzilla query for open bugs where either the official name or one of the
synonyms occurs in the summary. Maybe another query including fixed and
duplicate bugs.
[5. optionally:] links to some important mozilla.org docs about this UI element

(4.) is the most important thing here. The queries can be easily generated using
http://www.ags.uni-sb.de/~afranke/mozilla/quicksearch.html (see bug 61561).
For example, you can search for location field bugs by typing (without quotes):
"url,address,location bar,field" (comma means OR, space means AND). [One bug
seems to use "box", but if you say bar,field,box you add some noise to the
query]. In cases where not all combinations make sense, you can use queries like
"address bar","location field","urlbar" (this time with quotes).

This kind of index should be easy to integrate with documentation. Maybe some
annotated screenshots already exist. This can also be done with the main mail
window and some important dialog like prefs.

Another advantage of such an index would be that people who file new bugs could
look up the preferred term to denote the UI element their bug is related to.
If someone comes across a bug that uses an exotic term and is therefore missed
by the query, he can easily fix it by adding the prefered term in brackets at
the end of the summary.

If this kind of query-based index proves useful, it might be possible to
transfer this idea to other classes of terms, but I'm not sure how difficult
that would be.

Comment 1

[Gervase Markham [:gerv]]

Surely the problem here is that, for the majority of bugs, this doesn't really 
help. I mean that most bugs have little to do with the UI itself. Networking 
bugs, proxy bugs, rendering bugs...

Can you give more of an example of how this would help? Are we attempting to 
canonicalise descriptions of the UI elements? Because they are fairly canonical 
already, as I see it.

Gerv

Comment 2

[Andreas Franke (gone)]

I never claimed that this would solve all problems, thus _Partial_ index :)
And I mentioned the relation to the existing component system; it is expected
that this would help some components more than others.

Yes, we are trying to canonicalise the names for UI elements, but not just for
the sake of it. The goal is to make it easier to find bugs. Currently, if you
are looking for bugs that are about the URL bar not getting focus, you have to
search for "focus" and any combination of URL,location,address and bar,field ,
and you still don't know if you are missing an important one because there is at
least one urlbar bug that uses "box" instead of bar or field. Not everybody
knows that one has to use this complicated query to find the relevant bugs. And
at the time new bugs are filed, people use different terms.

I'm _not_ trying to make everyone use the same term, I'm completely ok with a
set of terms for each UI element. I'm don't have the illusion that everyone who
files unconfirmed bugs will consult several term indexes to make sure he uses
the same term others do. But I think it _is_ realistic to set up an advisory
rule that people who confirm bugs _should_ have a short glance at the summary
and try to make sure that all necessary terms appear in the summary to make this
bug show up in relevant queries. There will still be some bugs where this won't
happen, but their summaries can be fixed whenever this is detected, as it is
done now. But currently fixing the summaries is wizardry, really. You never know
what terms people will query for. This is not fair for people who file bugs
(their bugs may fall off radars and be marked duplicate of a newer bug just
because they used something else but the preferred term. And this is not fair
for people who query for bugs and can't find them because they are using a
non-standard term in their queries.

To avoid this mess, there should be a defined set of "official" names (I'm not
trying to restrict this to only one official term, in fact I'm saying this could
be a set of arbitrary cardinality, as long as it's finite). And I'm not claiming
that this has to be a static list that remains the same forever. If there is
demand later, any term could be added to that list.

Having such a set of names for each thing would give new bug reporters a better
chance for their bugs not to be forgotten, and it would make it much easier to
not miss important bugs in your query.
What I'm asking for here is that the knowledge about which terms are used for
things in Bugzilla be made explicit so that everybody can benefit from it.

Now UI elements are a good place to start because there is a natural way to
build this index: annotated screenshots. There is another area where this is not
too difficult: HTML elements. There is makes sense to have several indexes: a
graphical one every element is displayed on a page and annotated, one by tag
name <A>, maybe another one by common name: anchor, link.
But this probably can be (and should be) done with other areas, too. But in
these other areas it's probably difficult to have a graphical index.
That's why I was suggesting to start with UI elements. But you're right, the
problem I'm trying to solve here is a global one.

Comment 3

[Andreas Franke (gone)]

Another thing is that references to relevant docs for each thing may be useful.
Additionally it would probably help new contributors a lot if there were lxr
links to the code that implements the thing.

Comment 4

[Daniel Wang]

I'm thinking about creating a reference file for all the names and
descriptions people used to refer to Mozilla UI elements (n. grippy,
a. highlighted) and interactions (v. drag, a. feedback line). It
is more intended as a reference for acceptable bug summary terms
for QA people, but might work here.

Comment 5

[Reed Loden [:reed]]

--> Bugzilla: Other b.m.o Issues

Comment 6

[Dave Miller [:justdave]]

Given the way things are currently set up, this is probably more fit for developer.mozilla.org, and the folks there could probably do a way better job of maintaining it if it's implemented.  We could always link to it prominently from the correct places in Bugzilla if it gets set up.

Comment 7

[John Karahalis [:openjck]]

Going through some (really really) old bugs. This is probably now invalid, but at least doesn't fit within the current vision of the MDN. Moving over to Bugzilla to do what they wish.

Comment 8

[:glob ✱]

i agree with comment 6, it's a better fit for mdn.
if they consider it invalid, invalid it is.