Closed Bug 11155 Opened 25 years ago Closed 24 years ago

Support bug flags/tags/radars/keywords.

Categories

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

enhancement

Tracking

()

VERIFIED FIXED
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: 24 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: 24 years ago24 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
You need to log in before you can comment on or make changes to this bug.