Closed Bug 11155 Opened 26 years ago Closed 25 years ago

Support bug flags/tags/radars/keywords.

Categories

(Bugzilla :: Bugzilla-General, enhancement, P3)

Product:
Bugzilla
Component:
Bugzilla-General
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Bugzilla 2.12

People

(Reporter: CodeMachine, Assigned: tara)

References

Details

There is an increasing tendency to obscure descriptions with various "flags",
surrounded by braces, parentheses or brackets.  For example, in a search:

[PP]
[BLOCKER]
[OPT]
[CRASH]
[FEATURE]
[LAYER]
[RDF/XPCOM]
[USERAGENT]
[DOGFOOD]
[NATIVE-WIDGET]
[Necko]
[RFE]
[I18N]
[ENDER]
[4.xP]

... you get the picture.  I propose that since this is so common, there really
should be a way to specify certain flags on bugs instead of this.

A lot of these are redundant since there are already facilities for them, ie
RFE, Necko.  Still more of these use both marks and tracking bugs.  This
indicates there needs to be an easy way to display these on the bug list.

The advantages of having a set of flags are:

You'd see them on the bug screen as a set of checkboxes, hence are more likely
to fill them in, and let people find them.
There won't be many semantically equivalent flags with different spellings, and
hence prevent people finding them in queries.
You can easily query for the bugs with one of a set of flags.
Descriptions aren't cluttered unnecessarily on both the bug list and bug screen.

The trick of this is of course people will need to be able to see the flags on
the bug list.  How to display these is probably the most interesting question.
You could have them as a column on their own, or as a option to prepend them to
the description like what happens now, but it would be up to the queryer.

A possible disadvantage of this is that users can't define flags.  This may well
be a good thing.

You'd want to try and reduce the number of flags that are shown.  Hence you
might define flags that are for certain components.  This would be trickier,
since the flags that appear differ depending on the component control, and you
have to handle flags dropping off if they're no longer relevant to the
component.
The flags might be better off as a more compact representation if there's a lot
of them, eg a scrollable list box or a text-delimited text box, next to which is
a link to a list of flags.
*** Bug 17603 has been marked as a duplicate of this bug. ***
Summary: Support bug flags. → Support bug flags/tags/radars
What we should do is add a list box to the bug entry form, e.g. above the
comments box, which has entries like this:

   [RFE]  This is a feature request
   [perf]  Performance issue (optimisations, large files, etc)
   {ib}  Block-in-inline issue (LAYOUT TEAM ONLY!)
   {css-moz}  Issue with Mozilla's CSS extensions (IAN HICKSON ONLY!)
   [PDT+]  Definitely required for dogfood fix (NETSCAPE MANAGEMENT ONLY!)
   [PDT-]  Not necessary dogfood fix (NETSCAPE MANAGEMENT ONLY!)

(Check boxes would be unwieldly. Ever looked at this page in Lynx?)

You could then select multiple entries in this list, and when displaying a
bug's summary anywhere other than in the bug editing form, it would include
them as a space separated list, at the start. (Or possibly in a new column,
maybe this should be up to the user.)

Maybe when pretty-printing the bug for printing, it would even include the
selected radars' descriptions and include them before the "comments" section.

This would also need a new search option in the query field, just like the
status or resolution queries work now.

It is VERY important, however, that _anyone_ with a bugzilla account be able to
add radars to the list. Otherwise, we will get back to the situation we have
now where people need a new radar and so they just stick something in to the
summary field.

When adding a radar, you should have to include a short version and a brief
description, e.g.:

   Adding new radar.
          Code: [PDT+___]
   Description: [Not necessary dogfood fix (NETSCAPE MANAGEMENT ONLY!)_______]

   ((COMMIT)) ((RESET))  _Return_to_query_page_.

We probably also need an option for removing radars from the list, but I guess
that only the original inventor should be able to do that, and then probably
only once no bugs use that field. The original inventor should probably also
be able to change the bug's description.
Summary: Support bug flags/tags/radars → Anyone should be able to invent keywords!
Bugzilla now has a field for keywords/flags/tags/radars.

However, as I mentioned in the previous comment, it is IMPERATIVE that anyone
be able to invent new keywords, otherwise people will continue using the summary
and whiteboard fields for that purpose.

Currently, only "some central authority" can create new fields. In an open
source project like Mozilla, this strikes me as fundamentally wrong.

See my previous comments, starting from "It is VERY...".
While I'm not convinced anyone should be able to create new keywords, if it is
allowed, you should not just be able to enter a new keyword in the keywords
field of a bug.  Instead you should have to create it on a special page.

The main benefit of this is to prevent mistypings creating a new keyword and the
bug will be missed in a query.  This is the same as accounts at the moment and
has similar benefits.

I think it would also be better for keywords to be case-insensitive (ie forced
to the capitalisation given at definition time) since we currently see some
old-style keywords with different capitalisation which can also lead to bad
queries.

Old keywords can probably expire a certain period of time after there are no
bugs with them on them, if that ever occurs.  Basically this would mean any
central reference would be deleted (such as a facility saying who can add or
remove this keyword) as well as disappearing off any keywords list.

It's a bit hard for me to verify these things atm since the keywords seem
broken, and even so I wouldn't be using this stuff much.
There are two things here -- what the bugzilla code can support, and how it is
installed at bugzilla.mozilla.org.

The code can support a world where everyone can tweak keywords.  Basically, any
user in the "editkeywords" group can tweak keywords, and you can set it up so
that all users are automatically added to the editkeywords group.

Saying that  this is anti-open-source is ridiculous.  There are many things at
mozilla.org that are under control of some authority.  Even within
bugzilla.mozilla.org, you can't just go creating new projects and components;
you have to go through channels.  If Jan isn't doing a good job at maintaining
the keywords, then you should raise a stink until the situation improves.

What I'm hoping will happen is people will stick things into the status
whiteboard for short-term, limited scope interest, and will solicit Jan to make
a new keyword for things of wider interest.  But I don't want to see the keyword
space become polluted and confusing.
Ok, fair comment.

I'll contact Jan...
Status: NEW → ASSIGNED
tara@tequilarista.org is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
Status: ASSIGNED → NEW
OK, so is there some reason why this bug isn't closed?
Keywords work now right?

"Keywords work now" implies that they were at one point broken.  

:)

This bug just hit my radar, and after plodding my way through all the comments, 
I'm going to echo Terry's comment that this has to do with the implementation of 
bugzilla.mozilla.org rather than actual Bugzilla functionality (which already 
supports what is requested in principle).  Closing out...
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
I'm going to restore this bug for historical reasons to its original
description.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
It was done.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Summary: Anyone should be able to invent keywords! → Support bug flags/tags/radars/keywords.
Verif. feature present.
Status: RESOLVED → VERIFIED
In search of accurate queries....  (sorry for the spam)
Target Milestone: --- → Bugzilla 2.12
Moving closed bugs to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
QA Contact: matty
Version: other → unspecified
QA Contact: matty_is_a_geek → default-qa

I think pulsebot is broken. That was supposed to be issue #11155 in GitHub not in Bugzilla.

Flags: needinfo?(ctuns)
Flags: needinfo?(ctuns) → needinfo?(aryx.bugmail)
You need to log in before you can comment on or make changes to this bug.