Bug 126907 - remove "Future" section from guide.
git-svn-id: svn://10.0.0.236/trunk@120473 18797224-902f-48f8-a5cc-f745e15eee43
This commit is contained in:
gerv%gerv.net
parent
26b8ec03bc
commit
f2f011f5f4
@ -1,746 +0,0 @@
|
||||
<HTML
|
||||
><HEAD
|
||||
><TITLE
|
||||
>The Future of Bugzilla</TITLE
|
||||
><META
|
||||
NAME="GENERATOR"
|
||||
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
|
||||
"><LINK
|
||||
REL="HOME"
|
||||
TITLE="The Bugzilla Guide"
|
||||
HREF="index.html"><LINK
|
||||
REL="PREVIOUS"
|
||||
TITLE="Tinderbox/Tinderbox2"
|
||||
HREF="tinderbox.html"><LINK
|
||||
REL="NEXT"
|
||||
TITLE="Bugzilla Variants and Competitors"
|
||||
HREF="variants.html"></HEAD
|
||||
><BODY
|
||||
CLASS="chapter"
|
||||
BGCOLOR="#FFFFFF"
|
||||
TEXT="#000000"
|
||||
LINK="#0000FF"
|
||||
VLINK="#840084"
|
||||
ALINK="#0000FF"
|
||||
><DIV
|
||||
CLASS="NAVHEADER"
|
||||
><TABLE
|
||||
SUMMARY="Header navigation table"
|
||||
WIDTH="100%"
|
||||
BORDER="0"
|
||||
CELLPADDING="0"
|
||||
CELLSPACING="0"
|
||||
><TR
|
||||
><TH
|
||||
COLSPAN="3"
|
||||
ALIGN="center"
|
||||
>The Bugzilla Guide</TH
|
||||
></TR
|
||||
><TR
|
||||
><TD
|
||||
WIDTH="10%"
|
||||
ALIGN="left"
|
||||
VALIGN="bottom"
|
||||
><A
|
||||
HREF="tinderbox.html"
|
||||
ACCESSKEY="P"
|
||||
>Prev</A
|
||||
></TD
|
||||
><TD
|
||||
WIDTH="80%"
|
||||
ALIGN="center"
|
||||
VALIGN="bottom"
|
||||
></TD
|
||||
><TD
|
||||
WIDTH="10%"
|
||||
ALIGN="right"
|
||||
VALIGN="bottom"
|
||||
><A
|
||||
HREF="variants.html"
|
||||
ACCESSKEY="N"
|
||||
>Next</A
|
||||
></TD
|
||||
></TR
|
||||
></TABLE
|
||||
><HR
|
||||
ALIGN="LEFT"
|
||||
WIDTH="100%"></DIV
|
||||
><DIV
|
||||
CLASS="chapter"
|
||||
><H1
|
||||
><A
|
||||
NAME="future">Chapter 6. The Future of Bugzilla</H1
|
||||
><TABLE
|
||||
BORDER="0"
|
||||
BGCOLOR="#E0E0E0"
|
||||
WIDTH="100%"
|
||||
><TR
|
||||
><TD
|
||||
><FONT
|
||||
COLOR="#000000"
|
||||
><PRE
|
||||
CLASS="synopsis"
|
||||
>Bugzilla's Future. Much of this is the present, now.</PRE
|
||||
></FONT
|
||||
></TD
|
||||
></TR
|
||||
></TABLE
|
||||
><P
|
||||
> Bugzilla's future is a constantly-changing thing, as various developers
|
||||
<SPAN
|
||||
CLASS="QUOTE"
|
||||
>"scratch an itch"</SPAN
|
||||
> when it comes to functionality.
|
||||
Thus this section is very malleable, subject to change without notice, etc.
|
||||
You'll probably also notice the lack of formatting. I apologize that it's
|
||||
not quite as readable as the rest of the Guide.
|
||||
</P
|
||||
><P
|
||||
> <P
|
||||
CLASS="literallayout"
|
||||
><br>
|
||||
Bugzilla Blue Sky<br>
|
||||
<br>
|
||||
Customisability<br>
|
||||
<br>
|
||||
One of the major stumbling blocks of Bugzilla has been that it is too<br>
|
||||
rigid and does not adapt itself well enough to the needs of an<br>
|
||||
organisation. This has led to organisations making changes to the<br>
|
||||
Bugzilla code that need to be redone each new version of Bugzilla.<br>
|
||||
Bugzilla should attempt to move away from this to a world where this<br>
|
||||
doesn't need to occur.<br>
|
||||
<br>
|
||||
Most of the subsections in this section are currently explicit design<br>
|
||||
goals for the "Bugzilla 3" rewrite. This does not necessarily mean<br>
|
||||
that they will not occur before them in Bugzilla 2, but most are<br>
|
||||
significant undertakings.<br>
|
||||
<br>
|
||||
Field Customisation<br>
|
||||
<br>
|
||||
Many installations wish to customise the fields that appear on bug<br>
|
||||
reports. Current versions of Bugzilla offer limited<br>
|
||||
customisability. In particular, some fields can be turned off.<br>
|
||||
<br>
|
||||
However, many administrators wish to add their own fields, and rename<br>
|
||||
or otherwise modify existing fields. An architecture that supports<br>
|
||||
this would be extraordinarily useful.<br>
|
||||
<br>
|
||||
Indeed, many fields work similarly and could be abstracted into "field<br>
|
||||
types", so that an administrator need write little or no code to<br>
|
||||
support the new fields they desire.<br>
|
||||
<br>
|
||||
Possible field types include text (eg status whiteboard), numbers,<br>
|
||||
dates (eg report time), accounts (eg reporter, qa, cc), inter-bug<br>
|
||||
relationships (dependencies, duplicates), option groups (platform, os,<br>
|
||||
severity, priority, target milestone, version) etc.<br>
|
||||
<br>
|
||||
Ideally an administrator could configure their fields through a<br>
|
||||
Bugzilla interface that requires no code to be added. However, it is<br>
|
||||
highly unlikely this ideal will never be met, and in a similar way<br>
|
||||
that office applications have scripting languages, Bugzilla should<br>
|
||||
allow new field types to be written.<br>
|
||||
<br>
|
||||
Similarly, a common desire is for resolutions to be added or removed.<br>
|
||||
<br>
|
||||
Allocations<br>
|
||||
<br>
|
||||
?<br>
|
||||
<br>
|
||||
Option Groups<br>
|
||||
<br>
|
||||
?<br>
|
||||
<br>
|
||||
Relations<br>
|
||||
<br>
|
||||
?<br>
|
||||
<br>
|
||||
Database Integrity<br>
|
||||
<br>
|
||||
Furthermore, it is desirable for administrators to be able to specify<br>
|
||||
rules that must or should apply between the fields on a bug report.<br>
|
||||
<br>
|
||||
For example, you might wish to specify that a bug with status ASSIGNED<br>
|
||||
must have a target milestone field that that is not untargetted. Or<br>
|
||||
that a bug with a certain number of votes should get ASSIGNED. Or<br>
|
||||
that the QA contact must be different from the assignee.<br>
|
||||
<br>
|
||||
"Must" relationships could be implemented by refusing to make changes<br>
|
||||
that violate the relationships, or alternatively, automatically<br>
|
||||
updating certain fields in order to satisfy the criteria. Which<br>
|
||||
occurs should be up to the administrator.<br>
|
||||
<br>
|
||||
"Should" relationships could be implemented by a combination of<br>
|
||||
emitting warnings on the process bug page, the same on notification<br>
|
||||
mails, or emitting periodic whine mails about the situation. Again,<br>
|
||||
which occurs should be up to the administrator.<br>
|
||||
<br>
|
||||
It should also be possible for whine mails to be emitted for "must"<br>
|
||||
relationships, as they might become violated through direct database<br>
|
||||
access, Bugzilla bugs, or because they were there before the<br>
|
||||
relationship was enforced.<br>
|
||||
<br>
|
||||
As well as implementing intra-bug constraints, it would be useful to<br>
|
||||
create inter-bug constraints. For example, a bug that is dependent on<br>
|
||||
another bug should not have an earlier milestone or greater priority<br>
|
||||
than that bug.<br>
|
||||
<br>
|
||||
Database Adaptability<br>
|
||||
<br>
|
||||
Often an administrator desires that fields adapt to the values of<br>
|
||||
other fields. For example, the value of a field might determine the<br>
|
||||
possible values of another field or even whether it appears (whether<br>
|
||||
it is "applicable").<br>
|
||||
<br>
|
||||
Limited adaptability is present in Bugzilla 2, and only on the<br>
|
||||
"Product" field:<br>
|
||||
* The possible values of the target milestone, version and component<br>
|
||||
fields depend on the product.<br>
|
||||
* UNCONFIRMED can be turned off for specific products.<br>
|
||||
* Voting can be configured differently or turned off for different<br>
|
||||
products, and there is a separate user vote limits for each<br>
|
||||
product.<br>
|
||||
<br>
|
||||
It would be good if more adaptability was present, both in terms of<br>
|
||||
all fields relying on the product, as well as the ability to adapt<br>
|
||||
based on the value of all fields.<br>
|
||||
<br>
|
||||
Example ???<br>
|
||||
<br>
|
||||
General adaptability raises the issue of circular references between<br>
|
||||
fields causing problems. One possible solution to this is to place<br>
|
||||
the fields in a total ordering and require a field refer only to the<br>
|
||||
previous fields.<br>
|
||||
<br>
|
||||
In Bugzilla 2, changing the product of a bug meant a second page would<br>
|
||||
appear that allowed you to choose a new milestone, component and<br>
|
||||
version, as those fields adapted themselves to the new product. This<br>
|
||||
page could be generalised to support all instances where:<br>
|
||||
* a field value must or might be changed because the possible values<br>
|
||||
have changed<br>
|
||||
* is going to drop off because it it is no longer applicable, and<br>
|
||||
this should be confirmed<br>
|
||||
* must be specified because it is suddenly applicable, and the<br>
|
||||
default value, if one exists, might not be acceptable<br>
|
||||
<br>
|
||||
Database Independence<br>
|
||||
<br>
|
||||
Currently Bugzilla only runs on the MySQL database. It would be<br>
|
||||
desirable for Bugzilla to run on other databases, because:<br>
|
||||
* Organisations may have existing database products they use and<br>
|
||||
would prefer to run a homogenous environment.<br>
|
||||
* Databases each have their own shortcomings, including MySQL. An<br>
|
||||
administrator might choose a database that would work better with<br>
|
||||
their Bugzilla.<br>
|
||||
<br>
|
||||
This raises the possibility that we could use features that are only<br>
|
||||
present in some databases, by appropriately falling back. For<br>
|
||||
example, in the MySQL world, we live without:<br>
|
||||
* record-level locking, instead we use table-level locking<br>
|
||||
* referential and record constraints, instead we checking code<br>
|
||||
* subselects, instead we use multiple queries and redundant "caches"<br>
|
||||
<br>
|
||||
Multiple Front Ends<br>
|
||||
<br>
|
||||
Currently Bugzilla is manipulated via the Web, and notifies via<br>
|
||||
E-Mail. It would be desirable for Bugzilla to easily support various<br>
|
||||
front ends.<br>
|
||||
<br>
|
||||
There is no reason that Bugzilla could not be controlled via a whole<br>
|
||||
range of front ends, including Web, E-Mail, IRC, ICQ, etc, and<br>
|
||||
similarly for how it notifies. It's also possible that we could<br>
|
||||
introduce a special Bugzilla client that uses its own protocol, for<br>
|
||||
maximum user productivity.<br>
|
||||
<br>
|
||||
Indeed a request reply might be returned via a totally different<br>
|
||||
transport method than was use to submit the request.<br>
|
||||
<br>
|
||||
Internationalisation<br>
|
||||
<br>
|
||||
Bugzilla currently supports only English. All of the field names,<br>
|
||||
user instructions, etc are written in English. It would be desirable<br>
|
||||
to allow "language packs" so Bugzilla can be easily used in<br>
|
||||
non-English speaking locales.<br>
|
||||
<br>
|
||||
To a degree field customisation supports this, because administrators<br>
|
||||
could specify their own fields names anyway. However, there will<br>
|
||||
always be some basic facilities not covered by this, and it is<br>
|
||||
desirable that the administrator's interface also is<br>
|
||||
internationalisable.<br>
|
||||
<br>
|
||||
Better Searching<br>
|
||||
<br>
|
||||
General Summary Reports<br>
|
||||
<br>
|
||||
Sometimes, the normal querying page leaves a lot to be desired. There<br>
|
||||
are other facilities already in place or which people have asked for:<br>
|
||||
<br>
|
||||
Most Doomed Reports - All Bugs or All Bugs In A Product, Categorised<br>
|
||||
On Assignee, Shows and Counts Number of Bugs For Each Assignee<br>
|
||||
Most Voted For Bugs - All Bugs, Categorised On Product, Shows Top Ten<br>
|
||||
Bugs Voters Most Want Fixed<br>
|
||||
Number of Open Bugs For An Assignee - Bug List, Categorised On<br>
|
||||
Developers, Counts Number of Bugs In Category<br>
|
||||
<br>
|
||||
The important thing to realise is that people want categorised reports<br>
|
||||
on all sorts of things - a general summary report.<br>
|
||||
<br>
|
||||
In a categorised report, you choose the subset of bugs you wish to<br>
|
||||
operate on (similar to how you would specify a query), and then<br>
|
||||
categorise them on one or more fields.<br>
|
||||
<br>
|
||||
For each category you display the count of the number of things in<br>
|
||||
that category. You can optionally display the bugs themselves, or<br>
|
||||
leave them out, just showing the counts. And you can optionally limit<br>
|
||||
the number of things (bugs or subcategories) that display in each<br>
|
||||
category.<br>
|
||||
<br>
|
||||
Such a mechanism would let you do all of the above and more.<br>
|
||||
Applications of this mechanism would only be recognised once it was<br>
|
||||
implemented.<br>
|
||||
<br>
|
||||
Related Bugs<br>
|
||||
<br>
|
||||
It would be nice to have a field where you could enter other bugs<br>
|
||||
related to the current bug. It would be handy for navigation and<br>
|
||||
possibly even finding duplicates.<br>
|
||||
<br>
|
||||
Column Specification Support<br>
|
||||
<br>
|
||||
Currently bug lists use the columns that you last used. This doesn't<br>
|
||||
work well for "prepackaged queries", where you followed a link. You<br>
|
||||
can probably add a column by specifying a sort column, but this is<br>
|
||||
difficult and suboptimal.<br>
|
||||
<br>
|
||||
Furthermore, I find that when I want to add a column to a bug list,<br>
|
||||
it's usually a one off and I would prefer it to go away for the next<br>
|
||||
query. Hence, it would be nice to specify the columns that appear on<br>
|
||||
the bug list (and general summary report) pages. The default query<br>
|
||||
mechanism should be able to let you specify your default columns.<br>
|
||||
<br>
|
||||
Advanced Querying Redesign<br>
|
||||
<br>
|
||||
?<br>
|
||||
<br>
|
||||
Keywords<br>
|
||||
<br>
|
||||
People have a need to apply tags to bugs. In the beginning, people<br>
|
||||
placed designators in the summary and status whiteboard. However,<br>
|
||||
these fields were not designed for that, and so there were many flaws<br>
|
||||
with this system:<br>
|
||||
* They pollute the field with information that was never intended to<br>
|
||||
be present.<br>
|
||||
* Removing them with a bulk change is a difficult problem that has<br>
|
||||
too many pitfalls to implement.<br>
|
||||
* You can easily get the capitalisation wrong.<br>
|
||||
<br>
|
||||
Then dependencies were introduced (when?), and people realised that<br>
|
||||
they could use them for "tracking bugs". Again, dependencies were not<br>
|
||||
designed for that, and so there were more flaws, albeit different<br>
|
||||
ones, including:<br>
|
||||
* They aren't really bugs, so it's difficult to distinguish issues<br>
|
||||
from bugs.<br>
|
||||
* They can pollute bugs counts, and you must somehow exclude them<br>
|
||||
from queries.<br>
|
||||
* There is a whole lot of useless information on them. They have an<br>
|
||||
assignee but there is nothing to fix, and that person can get<br>
|
||||
whined at by Bugzilla. They have target milestones which must be<br>
|
||||
manually maintained. And so on.<br>
|
||||
<br>
|
||||
Finally, keywords were introduced (when?) for this purpose to remove<br>
|
||||
the need for these two systems. Unfortunately, the simple keywords<br>
|
||||
implementation was itself lacking in certain features provided by the<br>
|
||||
two previous systems, and has remained almost unchanged since its<br>
|
||||
inception. Furthermore, it could not be forseen that in large<br>
|
||||
installations, the sheer number of keywords could become unwieldly and<br>
|
||||
could lead to a movement back to the other systems.<br>
|
||||
<br>
|
||||
The keywords system was the right idea, however, and it remains so.<br>
|
||||
Fixing the keywords system is one of the most important Bugzilla<br>
|
||||
issues.<br>
|
||||
<br>
|
||||
Bringing Keywords Up To Par<br>
|
||||
<br>
|
||||
For the most part, keywords are very good at what they do. It is easy<br>
|
||||
to add and remove them (unlike summary/whiteboard designators), we can<br>
|
||||
simply see what issues are present on a bug (unlike tracking bugs),<br>
|
||||
and we do not confuse bugs with issues (unlike tracking bugs).<br>
|
||||
<br>
|
||||
However, there are still some "regressions" in the keyword system over<br>
|
||||
previous systems:<br>
|
||||
* Users wish to view the "dependency forest" of a keyword. While a<br>
|
||||
dependency tree is of one bug, a dependency forest is of a bug<br>
|
||||
list, and consists of a dependency tree for each member of the bug<br>
|
||||
list. Users can work around this with tracking bugs by creating a<br>
|
||||
tracking bug and viewing the dependency tree of that tracking bug.<br>
|
||||
* Users wish to specify the keywords that initially apply to a bug,<br>
|
||||
but instead they must edit the bug once it has already been<br>
|
||||
submitted. They can work around this with summary designators,<br>
|
||||
since they specify the summary at reporting time.<br>
|
||||
* Users wish to store or share a bug list that contains a keywords<br>
|
||||
column. Hence they wish to be able to specify what columns appear<br>
|
||||
in the bug list URL, as mentioned earlier. They can work around<br>
|
||||
this using summary designators, since almost all bug lists have a<br>
|
||||
summary column.<br>
|
||||
* Users wish to be able to view keywords on a bug list. However<br>
|
||||
often they are only interested in a small number of keywords.<br>
|
||||
Having a bug list with a keywords column means that all keywords<br>
|
||||
will appear on a bug list. This can take a substantial amount of<br>
|
||||
space where a bug has a lot of keywords, since the table columns<br>
|
||||
in Bugzilla adjust to the largest cell in that column. Hence<br>
|
||||
users wish to be able to specify which keywords should appear in<br>
|
||||
the bug list. In a very real sense, each keyword is a field unto<br>
|
||||
itself. Users can work around this by using summary designators,<br>
|
||||
since they keywords will share the space in the summary column.<br>
|
||||
* Users wish to know when bugs with a specific issue are resolved.<br>
|
||||
Hence they wish to be able to receive notifications on all the<br>
|
||||
bugs with a specific keyword. The introduction a generic watching<br>
|
||||
facility (also for things like watching all bugs in a component)<br>
|
||||
would achieve this. Users can work around this by using tracking<br>
|
||||
bugs, as dependencies have an existing way of detecting fixes to<br>
|
||||
bug a bug was blocked by.<br>
|
||||
<br>
|
||||
Dealing With The Keyword Overload<br>
|
||||
<br>
|
||||
At the time of writing, the mozilla.org installation has approximately<br>
|
||||
100 keywords, and many more would be in use if the keywords system<br>
|
||||
didn't have the problems it does.<br>
|
||||
<br>
|
||||
Such a large number of keywords introduces logistical problems:<br>
|
||||
* It must be easy for someone to learn what a keyword means. If a<br>
|
||||
keyword is buried within a lot of other keywords, it can be<br>
|
||||
difficult to find.<br>
|
||||
* It must be easy to see what keywords are on a bug. If the number<br>
|
||||
of keywords is large, then this can be difficult.<br>
|
||||
<br>
|
||||
These lead some people to feel that there are "too many keywords".<br>
|
||||
<br>
|
||||
These problems are not without solutions however. It is harder to<br>
|
||||
find a list of designators or tracking bugs than it is a list of<br>
|
||||
keywords.<br>
|
||||
<br>
|
||||
The essential problem is it needs to be easy to find the keywords<br>
|
||||
we're interested in through the mass of keywords.<br>
|
||||
<br>
|
||||
Keyword Applicability<br>
|
||||
<br>
|
||||
As has been previously mentioned, it is desirable for fields to be<br>
|
||||
able to adapt to the values of other fields. This is certainly true<br>
|
||||
for keywords. Many keywords are simply not relevant because of the<br>
|
||||
bugs product, component, etc.<br>
|
||||
<br>
|
||||
Hence, by introducing keyword applicability, and not displaying<br>
|
||||
keywords that are not relevant to the current bug, or clearly<br>
|
||||
separating them, we can make the keyword overload problem less<br>
|
||||
significant.<br>
|
||||
<br>
|
||||
Currently when you click on "keywords" on a bug, you get a list of all<br>
|
||||
bugs. It would be desirable to introduce a list of keywords tailored<br>
|
||||
to a specific bug, that reports, in order:<br>
|
||||
* the keywords currently on the bug<br>
|
||||
* the keywords not currently on the bug, but applicable to the bug<br>
|
||||
* optionally, the keywords not applicable to the bug<br>
|
||||
<br>
|
||||
This essentially orders the keywords into three groups, where each<br>
|
||||
group is more important than the previous, and therefore appears<br>
|
||||
closer to the top.<br>
|
||||
<br>
|
||||
Keyword Grouping & Ordering<br>
|
||||
<br>
|
||||
We could further enhance both the global and bug specific keyword list<br>
|
||||
by grouping keywords. We should always have a "flat" view of<br>
|
||||
keywords, but other ways of viewing the keywords would be useful too.<br>
|
||||
<br>
|
||||
If keyword applicability was implemented, we could group keywords<br>
|
||||
based on their "applicability condition". Keywords that apply to all<br>
|
||||
bugs could be separated from keywords that apply to a specific<br>
|
||||
product, both on the global keyword list and the keyword list of a bug<br>
|
||||
that is in that product.<br>
|
||||
<br>
|
||||
We could specify groups of our own. For example, many keywords are in<br>
|
||||
a mutually exclusive group, essentially like radio buttons in a user<br>
|
||||
interface. This creates a natural grouping, although other groupings<br>
|
||||
occur (which depends on your keywords).<br>
|
||||
<br>
|
||||
It is possible that we could use collapsing/expanding operations on<br>
|
||||
"twisties" to only should the groups we are interested in.<br>
|
||||
<br>
|
||||
And instead of grouping keywords, we could order them on some metric<br>
|
||||
of usefulness, such as:<br>
|
||||
* when the keyword was last added to a bug<br>
|
||||
* how many bugs the keyword is on<br>
|
||||
* how many open bugs the keyword is on<br>
|
||||
<br>
|
||||
Opting Out Of Keywords<br>
|
||||
<br>
|
||||
Not all people are going to care about all keywords. Therefore it<br>
|
||||
makes sense that you may wish to specify which keywords you are<br>
|
||||
interested in, either on the bug page, or on notifications.<br>
|
||||
<br>
|
||||
Other keywords will therefore not bother users who are not interested<br>
|
||||
in them.<br>
|
||||
<br>
|
||||
Keyword Security<br>
|
||||
<br>
|
||||
Currently all keywords are available and editable to all people with<br>
|
||||
edit bugs access. This situation is clearly suboptimal.<br>
|
||||
<br>
|
||||
Although relying on good behaviour for people to not do what they<br>
|
||||
shouldn't works reasonably well on the mozilla.org, it is better to<br>
|
||||
enforce that behaviour - it can be breached through malice, accident<br>
|
||||
or ignorance.<br>
|
||||
<br>
|
||||
And in the situation where it is desirable for the presence or absence<br>
|
||||
of a keyword not to be revealed, organisations either need to be<br>
|
||||
content with the divulgence, or not use keywords at all.<br>
|
||||
<br>
|
||||
In the situation where they choose to divulge, introducing the ability<br>
|
||||
to restrict who can see the keyword would also reduce keyword<br>
|
||||
overload.<br>
|
||||
<br>
|
||||
Personal Keywords<br>
|
||||
<br>
|
||||
Keywords join together a set of bugs which would otherwise be<br>
|
||||
unrelated in the bug system.<br>
|
||||
<br>
|
||||
We allow users to store their own queries. However we don't allow<br>
|
||||
them to store their own keywords on a bug. This reduces the<br>
|
||||
usefulness of personal queries, since you cannot join a set of<br>
|
||||
unrelated bugs together in a way that you wish. Lists of bug numbers<br>
|
||||
can work, by they can only be used for small lists, and it is<br>
|
||||
impossible to share a list between multiple queries.<br>
|
||||
<br>
|
||||
Personal keywords are necessary to replace personal tracking bugs, as<br>
|
||||
they would not pollute the keyword space. Indeed, on many<br>
|
||||
installations this could remove some keywords out of the global<br>
|
||||
keyword space.<br>
|
||||
<br>
|
||||
In a similar vein and with similar effects, group keywords could be<br>
|
||||
introduced that are only available to members of a specific group.<br>
|
||||
<br>
|
||||
Keyword Restrictions<br>
|
||||
<br>
|
||||
Keywords are not islands unto themselves. Along with their potential<br>
|
||||
to be involved in the inter-field relationships mentioned earlier,<br>
|
||||
keywords can also be related to other keywords.<br>
|
||||
<br>
|
||||
Essentially, there are two possibilities:<br>
|
||||
* a set of keywords are mutually exclusive<br>
|
||||
* the presence of a keyword implies another keyword must be present<br>
|
||||
<br>
|
||||
Introduction of the ability to specify these restrictions would have<br>
|
||||
benefits.<br>
|
||||
<br>
|
||||
If mutually exclusive keywords were present on a bug, their removal<br>
|
||||
would fix up the database, as well as reducing the number of keywords<br>
|
||||
on that bug.<br>
|
||||
<br>
|
||||
In the situation where a keyword implies another keyword, there are<br>
|
||||
two possiblities as to how to handle the situation.<br>
|
||||
<br>
|
||||
The first is automatically add the keyword. This would fix up the<br>
|
||||
database, but it would increase the number of keywords on a bug.<br>
|
||||
<br>
|
||||
The second is to automatically remove the keyword, and alter queries<br>
|
||||
so they pick up the first keyword as well as the removed keyword.<br>
|
||||
This would fix up the database and reduce the number of keywords on a<br>
|
||||
bug, but it might confuse users who don't see the keyword.<br>
|
||||
Alternatively, the implied keywords could be listed separately.<br>
|
||||
<br>
|
||||
Notifications<br>
|
||||
<br>
|
||||
Every time a bug gets changed notifications get sent out to people<br>
|
||||
letting them know about what changes have been made. This is a<br>
|
||||
significant feature, and all sorts of questions can be raised, but<br>
|
||||
they mainly boil down to when they should be sent and what they should<br>
|
||||
look like.<br>
|
||||
<br>
|
||||
Changes You're Interested In<br>
|
||||
<br>
|
||||
As of version 2.12 users can specify what sort of changes they are<br>
|
||||
interested in receiving notifications for. However, this is still<br>
|
||||
limited. As yet there is no facility to specify which keywords you<br>
|
||||
care about, and whether you care about changes to fields such as the<br>
|
||||
QA contact changes.<br>
|
||||
Furthermore, often an unnecessary comment will go along with a change,<br>
|
||||
either because it is required, or the commenter is ignorant of how the<br>
|
||||
new system works. While explaining why you did something is useful,<br>
|
||||
merely commenting on what you did is not because that information is<br>
|
||||
already accessible view "Bug Activity".<br>
|
||||
<br>
|
||||
Because of this unnecessary comment, a lot of changes that would<br>
|
||||
otherwise not generate notifications for certain people do so, because<br>
|
||||
few people are willing to turn off comments. One way to deal with<br>
|
||||
this problem is to allow people to specify that their comments are<br>
|
||||
purely explanatory, and that anyone who is not interested in the<br>
|
||||
change will not be interested in the comment.<br>
|
||||
<br>
|
||||
Furthermore, one possible rationale for unnecessary comments is that<br>
|
||||
the bug activity does not display on the normal page and hence it is<br>
|
||||
difficult to cross reference comments and actions. Hence, it would be<br>
|
||||
beneficial to be able to do this.<br>
|
||||
<br>
|
||||
Bugs You're Watching<br>
|
||||
<br>
|
||||
Currently to receive a notification about a bug you need to have your<br>
|
||||
name on it. This is suboptimal because you need to know about a bug<br>
|
||||
before you can receive notifications on it. Often you are interested<br>
|
||||
in any bug with a field set to a specific value. For example, you<br>
|
||||
might be interested in all bugs with a specific product, component or<br>
|
||||
keyword.<br>
|
||||
<br>
|
||||
If someone could automatically receive notifications about these bugs,<br>
|
||||
it would make everyone's lives easier. Currently the default assignee<br>
|
||||
and QA contact for a component will automatically receive<br>
|
||||
notifications for<br>
|
||||
<br>
|
||||
Question: This moves half way to a BCC.<br>
|
||||
<br>
|
||||
Bulk Changes<br>
|
||||
<br>
|
||||
A very useful feature of Bugzilla is the ability to perform an action<br>
|
||||
on multiple bugs at once. However, this means that similar<br>
|
||||
notifications are currently generated for each bug modified.<br>
|
||||
<br>
|
||||
This can result in a torrent of notifications that can annoy.<br>
|
||||
<br>
|
||||
Furthermore, since the bugs are all changed close to each other in<br>
|
||||
time, it is easy for someone to mass delete all the notifications<br>
|
||||
generated by a bulk change and miss an unrelated notification in the<br>
|
||||
middle.<br>
|
||||
<br>
|
||||
These factors can lead to a tendency for people to delay bulk changes,<br>
|
||||
or avoid them entirely. This is suboptimal.<br>
|
||||
<br>
|
||||
It would be better if a bulk change generated only one notification<br>
|
||||
mail. This would vastly reduce the annoyance factor, and prevent<br>
|
||||
accidental deletion of notifications.<br>
|
||||
<br>
|
||||
One problem with this change is that some people separate out<br>
|
||||
notifications using filtering. This means that they would no longer<br>
|
||||
be match parts of a bulk change under different filtering rules.<br>
|
||||
<br>
|
||||
One possibility to resolve this is to allow people to specify groups<br>
|
||||
of bugs. All bugs within a group would go into the same<br>
|
||||
notification. The filters could then distinguish the different bug<br>
|
||||
groups.<br>
|
||||
<br>
|
||||
In any case, it is likely there would need to be a transition period<br>
|
||||
to allow people to alter their filters.<br>
|
||||
<br>
|
||||
Nominations<br>
|
||||
<br>
|
||||
?<br>
|
||||
<br>
|
||||
Linking Bugzilla Installations<br>
|
||||
<br>
|
||||
The first example of linking Bugzilla installations together has is<br>
|
||||
the introduction of bug moving in version 2.12. However, it would be<br>
|
||||
useful to be able to link installations in more ways.<br>
|
||||
* Dependencies and other relationships between bugs in other<br>
|
||||
installations. This is difficult because dependencies are<br>
|
||||
synchronised on both bugs, so the installation that changes<br>
|
||||
dependencies would need to communicate the new state to the other<br>
|
||||
installation. It would also mean that relationships and<br>
|
||||
notifications that refer to other bugs would need to communicate<br>
|
||||
with the other installation.<br>
|
||||
* References to bugs in other installations. Currently if you type<br>
|
||||
"bug XXX" or "bug #XXX" where XXX is a number, you get an<br>
|
||||
automatic hyperlink to that bug. It would be useful if you could<br>
|
||||
say "YYY bug #XXX" where YYY is the name of another installation.<br>
|
||||
<br>
|
||||
Retirement<br>
|
||||
<br>
|
||||
?<br>
|
||||
<br>
|
||||
Whiny Reports<br>
|
||||
<br>
|
||||
?<br>
|
||||
<br>
|
||||
Group Redesign<br>
|
||||
<br>
|
||||
?<br>
|
||||
<br>
|
||||
Hard Wrapping Comments<br>
|
||||
<br>
|
||||
Currently Bugzilla "hard wraps" its comments to a specific line size,<br>
|
||||
similar to E-Mail. This has various problems:<br>
|
||||
* The way it currently works, wrapping is done in the browser at<br>
|
||||
submission time using a non-standard HTML extension not supported<br>
|
||||
by some (uncommon) browsers. These browsers generate comments<br>
|
||||
that scroll off the right side of the screen.<br>
|
||||
* Because comments are of fixed width, when you expand your browser<br>
|
||||
window, the comments do not expand to fit available space.<br>
|
||||
<br>
|
||||
It would be much better to move to a world of soft wrapping, where the<br>
|
||||
browser wraps the text at display time, similar to a world processor.<br>
|
||||
And as in a word processor, soft wrapping does not preclude the<br>
|
||||
insertion of newlines.<br>
|
||||
<br>
|
||||
Hard wrapping is too entrenched into text E-Mail to fix, but we can<br>
|
||||
fix Bugzilla without causing any problems. The old content will still<br>
|
||||
be wrapped too early, but at least new content will work.<br>
|
||||
</P
|
||||
>
|
||||
</P
|
||||
></DIV
|
||||
><DIV
|
||||
CLASS="NAVFOOTER"
|
||||
><HR
|
||||
ALIGN="LEFT"
|
||||
WIDTH="100%"><TABLE
|
||||
SUMMARY="Footer navigation table"
|
||||
WIDTH="100%"
|
||||
BORDER="0"
|
||||
CELLPADDING="0"
|
||||
CELLSPACING="0"
|
||||
><TR
|
||||
><TD
|
||||
WIDTH="33%"
|
||||
ALIGN="left"
|
||||
VALIGN="top"
|
||||
><A
|
||||
HREF="tinderbox.html"
|
||||
ACCESSKEY="P"
|
||||
>Prev</A
|
||||
></TD
|
||||
><TD
|
||||
WIDTH="34%"
|
||||
ALIGN="center"
|
||||
VALIGN="top"
|
||||
><A
|
||||
HREF="index.html"
|
||||
ACCESSKEY="H"
|
||||
>Home</A
|
||||
></TD
|
||||
><TD
|
||||
WIDTH="33%"
|
||||
ALIGN="right"
|
||||
VALIGN="top"
|
||||
><A
|
||||
HREF="variants.html"
|
||||
ACCESSKEY="N"
|
||||
>Next</A
|
||||
></TD
|
||||
></TR
|
||||
><TR
|
||||
><TD
|
||||
WIDTH="33%"
|
||||
ALIGN="left"
|
||||
VALIGN="top"
|
||||
>Tinderbox/Tinderbox2</TD
|
||||
><TD
|
||||
WIDTH="34%"
|
||||
ALIGN="center"
|
||||
VALIGN="top"
|
||||
> </TD
|
||||
><TD
|
||||
WIDTH="33%"
|
||||
ALIGN="right"
|
||||
VALIGN="top"
|
||||
>Bugzilla Variants and Competitors</TD
|
||||
></TR
|
||||
></TABLE
|
||||
></DIV
|
||||
></BODY
|
||||
></HTML
|
||||
>
|
||||
@ -193,9 +193,6 @@ try to avoid clutter and feel free to waste space in the code to make it more re
|
||||
<!-- Integrating Bugzilla with Third-Party Tools -->
|
||||
&integration;
|
||||
|
||||
<!-- The Future of Bugzilla -->
|
||||
&future;
|
||||
|
||||
<!-- Major Bugzilla Variants -->
|
||||
&variants;
|
||||
|
||||
|
||||
@ -1,619 +0,0 @@
|
||||
<!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook V4.1//EN" > -->
|
||||
|
||||
<chapter id="future">
|
||||
<title>The Future of Bugzilla</title>
|
||||
<synopsis>Bugzilla's Future. Much of this is the present, now.</synopsis>
|
||||
<para>
|
||||
Bugzilla's future is a constantly-changing thing, as various developers
|
||||
<quote>scratch an itch</quote> when it comes to functionality.
|
||||
Thus this section is very malleable, subject to change without notice, etc.
|
||||
You'll probably also notice the lack of formatting. I apologize that it's
|
||||
not quite as readable as the rest of the Guide.
|
||||
</para>
|
||||
<para>
|
||||
<literallayout>
|
||||
Bugzilla Blue Sky
|
||||
|
||||
Customisability
|
||||
|
||||
One of the major stumbling blocks of Bugzilla has been that it is too
|
||||
rigid and does not adapt itself well enough to the needs of an
|
||||
organisation. This has led to organisations making changes to the
|
||||
Bugzilla code that need to be redone each new version of Bugzilla.
|
||||
Bugzilla should attempt to move away from this to a world where this
|
||||
doesn't need to occur.
|
||||
|
||||
Most of the subsections in this section are currently explicit design
|
||||
goals for the "Bugzilla 3" rewrite. This does not necessarily mean
|
||||
that they will not occur before them in Bugzilla 2, but most are
|
||||
significant undertakings.
|
||||
|
||||
Field Customisation
|
||||
|
||||
Many installations wish to customise the fields that appear on bug
|
||||
reports. Current versions of Bugzilla offer limited
|
||||
customisability. In particular, some fields can be turned off.
|
||||
|
||||
However, many administrators wish to add their own fields, and rename
|
||||
or otherwise modify existing fields. An architecture that supports
|
||||
this would be extraordinarily useful.
|
||||
|
||||
Indeed, many fields work similarly and could be abstracted into "field
|
||||
types", so that an administrator need write little or no code to
|
||||
support the new fields they desire.
|
||||
|
||||
Possible field types include text (eg status whiteboard), numbers,
|
||||
dates (eg report time), accounts (eg reporter, qa, cc), inter-bug
|
||||
relationships (dependencies, duplicates), option groups (platform, os,
|
||||
severity, priority, target milestone, version) etc.
|
||||
|
||||
Ideally an administrator could configure their fields through a
|
||||
Bugzilla interface that requires no code to be added. However, it is
|
||||
highly unlikely this ideal will never be met, and in a similar way
|
||||
that office applications have scripting languages, Bugzilla should
|
||||
allow new field types to be written.
|
||||
|
||||
Similarly, a common desire is for resolutions to be added or removed.
|
||||
|
||||
Allocations
|
||||
|
||||
?
|
||||
|
||||
Option Groups
|
||||
|
||||
?
|
||||
|
||||
Relations
|
||||
|
||||
?
|
||||
|
||||
Database Integrity
|
||||
|
||||
Furthermore, it is desirable for administrators to be able to specify
|
||||
rules that must or should apply between the fields on a bug report.
|
||||
|
||||
For example, you might wish to specify that a bug with status ASSIGNED
|
||||
must have a target milestone field that that is not untargetted. Or
|
||||
that a bug with a certain number of votes should get ASSIGNED. Or
|
||||
that the QA contact must be different from the assignee.
|
||||
|
||||
"Must" relationships could be implemented by refusing to make changes
|
||||
that violate the relationships, or alternatively, automatically
|
||||
updating certain fields in order to satisfy the criteria. Which
|
||||
occurs should be up to the administrator.
|
||||
|
||||
"Should" relationships could be implemented by a combination of
|
||||
emitting warnings on the process bug page, the same on notification
|
||||
mails, or emitting periodic whine mails about the situation. Again,
|
||||
which occurs should be up to the administrator.
|
||||
|
||||
It should also be possible for whine mails to be emitted for "must"
|
||||
relationships, as they might become violated through direct database
|
||||
access, Bugzilla bugs, or because they were there before the
|
||||
relationship was enforced.
|
||||
|
||||
As well as implementing intra-bug constraints, it would be useful to
|
||||
create inter-bug constraints. For example, a bug that is dependent on
|
||||
another bug should not have an earlier milestone or greater priority
|
||||
than that bug.
|
||||
|
||||
Database Adaptability
|
||||
|
||||
Often an administrator desires that fields adapt to the values of
|
||||
other fields. For example, the value of a field might determine the
|
||||
possible values of another field or even whether it appears (whether
|
||||
it is "applicable").
|
||||
|
||||
Limited adaptability is present in Bugzilla 2, and only on the
|
||||
"Product" field:
|
||||
* The possible values of the target milestone, version and component
|
||||
fields depend on the product.
|
||||
* UNCONFIRMED can be turned off for specific products.
|
||||
* Voting can be configured differently or turned off for different
|
||||
products, and there is a separate user vote limits for each
|
||||
product.
|
||||
|
||||
It would be good if more adaptability was present, both in terms of
|
||||
all fields relying on the product, as well as the ability to adapt
|
||||
based on the value of all fields.
|
||||
|
||||
Example ???
|
||||
|
||||
General adaptability raises the issue of circular references between
|
||||
fields causing problems. One possible solution to this is to place
|
||||
the fields in a total ordering and require a field refer only to the
|
||||
previous fields.
|
||||
|
||||
In Bugzilla 2, changing the product of a bug meant a second page would
|
||||
appear that allowed you to choose a new milestone, component and
|
||||
version, as those fields adapted themselves to the new product. This
|
||||
page could be generalised to support all instances where:
|
||||
* a field value must or might be changed because the possible values
|
||||
have changed
|
||||
* is going to drop off because it it is no longer applicable, and
|
||||
this should be confirmed
|
||||
* must be specified because it is suddenly applicable, and the
|
||||
default value, if one exists, might not be acceptable
|
||||
|
||||
Database Independence
|
||||
|
||||
Currently Bugzilla only runs on the MySQL database. It would be
|
||||
desirable for Bugzilla to run on other databases, because:
|
||||
* Organisations may have existing database products they use and
|
||||
would prefer to run a homogenous environment.
|
||||
* Databases each have their own shortcomings, including MySQL. An
|
||||
administrator might choose a database that would work better with
|
||||
their Bugzilla.
|
||||
|
||||
This raises the possibility that we could use features that are only
|
||||
present in some databases, by appropriately falling back. For
|
||||
example, in the MySQL world, we live without:
|
||||
* record-level locking, instead we use table-level locking
|
||||
* referential and record constraints, instead we checking code
|
||||
* subselects, instead we use multiple queries and redundant "caches"
|
||||
|
||||
Multiple Front Ends
|
||||
|
||||
Currently Bugzilla is manipulated via the Web, and notifies via
|
||||
E-Mail. It would be desirable for Bugzilla to easily support various
|
||||
front ends.
|
||||
|
||||
There is no reason that Bugzilla could not be controlled via a whole
|
||||
range of front ends, including Web, E-Mail, IRC, ICQ, etc, and
|
||||
similarly for how it notifies. It's also possible that we could
|
||||
introduce a special Bugzilla client that uses its own protocol, for
|
||||
maximum user productivity.
|
||||
|
||||
Indeed a request reply might be returned via a totally different
|
||||
transport method than was use to submit the request.
|
||||
|
||||
Internationalisation
|
||||
|
||||
Bugzilla currently supports only English. All of the field names,
|
||||
user instructions, etc are written in English. It would be desirable
|
||||
to allow "language packs" so Bugzilla can be easily used in
|
||||
non-English speaking locales.
|
||||
|
||||
To a degree field customisation supports this, because administrators
|
||||
could specify their own fields names anyway. However, there will
|
||||
always be some basic facilities not covered by this, and it is
|
||||
desirable that the administrator's interface also is
|
||||
internationalisable.
|
||||
|
||||
Better Searching
|
||||
|
||||
General Summary Reports
|
||||
|
||||
Sometimes, the normal querying page leaves a lot to be desired. There
|
||||
are other facilities already in place or which people have asked for:
|
||||
|
||||
Most Doomed Reports - All Bugs or All Bugs In A Product, Categorised
|
||||
On Assignee, Shows and Counts Number of Bugs For Each Assignee
|
||||
Most Voted For Bugs - All Bugs, Categorised On Product, Shows Top Ten
|
||||
Bugs Voters Most Want Fixed
|
||||
Number of Open Bugs For An Assignee - Bug List, Categorised On
|
||||
Developers, Counts Number of Bugs In Category
|
||||
|
||||
The important thing to realise is that people want categorised reports
|
||||
on all sorts of things - a general summary report.
|
||||
|
||||
In a categorised report, you choose the subset of bugs you wish to
|
||||
operate on (similar to how you would specify a query), and then
|
||||
categorise them on one or more fields.
|
||||
|
||||
For each category you display the count of the number of things in
|
||||
that category. You can optionally display the bugs themselves, or
|
||||
leave them out, just showing the counts. And you can optionally limit
|
||||
the number of things (bugs or subcategories) that display in each
|
||||
category.
|
||||
|
||||
Such a mechanism would let you do all of the above and more.
|
||||
Applications of this mechanism would only be recognised once it was
|
||||
implemented.
|
||||
|
||||
Related Bugs
|
||||
|
||||
It would be nice to have a field where you could enter other bugs
|
||||
related to the current bug. It would be handy for navigation and
|
||||
possibly even finding duplicates.
|
||||
|
||||
Column Specification Support
|
||||
|
||||
Currently bug lists use the columns that you last used. This doesn't
|
||||
work well for "prepackaged queries", where you followed a link. You
|
||||
can probably add a column by specifying a sort column, but this is
|
||||
difficult and suboptimal.
|
||||
|
||||
Furthermore, I find that when I want to add a column to a bug list,
|
||||
it's usually a one off and I would prefer it to go away for the next
|
||||
query. Hence, it would be nice to specify the columns that appear on
|
||||
the bug list (and general summary report) pages. The default query
|
||||
mechanism should be able to let you specify your default columns.
|
||||
|
||||
Advanced Querying Redesign
|
||||
|
||||
?
|
||||
|
||||
Keywords
|
||||
|
||||
People have a need to apply tags to bugs. In the beginning, people
|
||||
placed designators in the summary and status whiteboard. However,
|
||||
these fields were not designed for that, and so there were many flaws
|
||||
with this system:
|
||||
* They pollute the field with information that was never intended to
|
||||
be present.
|
||||
* Removing them with a bulk change is a difficult problem that has
|
||||
too many pitfalls to implement.
|
||||
* You can easily get the capitalisation wrong.
|
||||
|
||||
Then dependencies were introduced (when?), and people realised that
|
||||
they could use them for "tracking bugs". Again, dependencies were not
|
||||
designed for that, and so there were more flaws, albeit different
|
||||
ones, including:
|
||||
* They aren't really bugs, so it's difficult to distinguish issues
|
||||
from bugs.
|
||||
* They can pollute bugs counts, and you must somehow exclude them
|
||||
from queries.
|
||||
* There is a whole lot of useless information on them. They have an
|
||||
assignee but there is nothing to fix, and that person can get
|
||||
whined at by Bugzilla. They have target milestones which must be
|
||||
manually maintained. And so on.
|
||||
|
||||
Finally, keywords were introduced (when?) for this purpose to remove
|
||||
the need for these two systems. Unfortunately, the simple keywords
|
||||
implementation was itself lacking in certain features provided by the
|
||||
two previous systems, and has remained almost unchanged since its
|
||||
inception. Furthermore, it could not be forseen that in large
|
||||
installations, the sheer number of keywords could become unwieldly and
|
||||
could lead to a movement back to the other systems.
|
||||
|
||||
The keywords system was the right idea, however, and it remains so.
|
||||
Fixing the keywords system is one of the most important Bugzilla
|
||||
issues.
|
||||
|
||||
Bringing Keywords Up To Par
|
||||
|
||||
For the most part, keywords are very good at what they do. It is easy
|
||||
to add and remove them (unlike summary/whiteboard designators), we can
|
||||
simply see what issues are present on a bug (unlike tracking bugs),
|
||||
and we do not confuse bugs with issues (unlike tracking bugs).
|
||||
|
||||
However, there are still some "regressions" in the keyword system over
|
||||
previous systems:
|
||||
* Users wish to view the "dependency forest" of a keyword. While a
|
||||
dependency tree is of one bug, a dependency forest is of a bug
|
||||
list, and consists of a dependency tree for each member of the bug
|
||||
list. Users can work around this with tracking bugs by creating a
|
||||
tracking bug and viewing the dependency tree of that tracking bug.
|
||||
* Users wish to specify the keywords that initially apply to a bug,
|
||||
but instead they must edit the bug once it has already been
|
||||
submitted. They can work around this with summary designators,
|
||||
since they specify the summary at reporting time.
|
||||
* Users wish to store or share a bug list that contains a keywords
|
||||
column. Hence they wish to be able to specify what columns appear
|
||||
in the bug list URL, as mentioned earlier. They can work around
|
||||
this using summary designators, since almost all bug lists have a
|
||||
summary column.
|
||||
* Users wish to be able to view keywords on a bug list. However
|
||||
often they are only interested in a small number of keywords.
|
||||
Having a bug list with a keywords column means that all keywords
|
||||
will appear on a bug list. This can take a substantial amount of
|
||||
space where a bug has a lot of keywords, since the table columns
|
||||
in Bugzilla adjust to the largest cell in that column. Hence
|
||||
users wish to be able to specify which keywords should appear in
|
||||
the bug list. In a very real sense, each keyword is a field unto
|
||||
itself. Users can work around this by using summary designators,
|
||||
since they keywords will share the space in the summary column.
|
||||
* Users wish to know when bugs with a specific issue are resolved.
|
||||
Hence they wish to be able to receive notifications on all the
|
||||
bugs with a specific keyword. The introduction a generic watching
|
||||
facility (also for things like watching all bugs in a component)
|
||||
would achieve this. Users can work around this by using tracking
|
||||
bugs, as dependencies have an existing way of detecting fixes to
|
||||
bug a bug was blocked by.
|
||||
|
||||
Dealing With The Keyword Overload
|
||||
|
||||
At the time of writing, the mozilla.org installation has approximately
|
||||
100 keywords, and many more would be in use if the keywords system
|
||||
didn't have the problems it does.
|
||||
|
||||
Such a large number of keywords introduces logistical problems:
|
||||
* It must be easy for someone to learn what a keyword means. If a
|
||||
keyword is buried within a lot of other keywords, it can be
|
||||
difficult to find.
|
||||
* It must be easy to see what keywords are on a bug. If the number
|
||||
of keywords is large, then this can be difficult.
|
||||
|
||||
These lead some people to feel that there are "too many keywords".
|
||||
|
||||
These problems are not without solutions however. It is harder to
|
||||
find a list of designators or tracking bugs than it is a list of
|
||||
keywords.
|
||||
|
||||
The essential problem is it needs to be easy to find the keywords
|
||||
we're interested in through the mass of keywords.
|
||||
|
||||
Keyword Applicability
|
||||
|
||||
As has been previously mentioned, it is desirable for fields to be
|
||||
able to adapt to the values of other fields. This is certainly true
|
||||
for keywords. Many keywords are simply not relevant because of the
|
||||
bugs product, component, etc.
|
||||
|
||||
Hence, by introducing keyword applicability, and not displaying
|
||||
keywords that are not relevant to the current bug, or clearly
|
||||
separating them, we can make the keyword overload problem less
|
||||
significant.
|
||||
|
||||
Currently when you click on "keywords" on a bug, you get a list of all
|
||||
bugs. It would be desirable to introduce a list of keywords tailored
|
||||
to a specific bug, that reports, in order:
|
||||
* the keywords currently on the bug
|
||||
* the keywords not currently on the bug, but applicable to the bug
|
||||
* optionally, the keywords not applicable to the bug
|
||||
|
||||
This essentially orders the keywords into three groups, where each
|
||||
group is more important than the previous, and therefore appears
|
||||
closer to the top.
|
||||
|
||||
Keyword Grouping & Ordering
|
||||
|
||||
We could further enhance both the global and bug specific keyword list
|
||||
by grouping keywords. We should always have a "flat" view of
|
||||
keywords, but other ways of viewing the keywords would be useful too.
|
||||
|
||||
If keyword applicability was implemented, we could group keywords
|
||||
based on their "applicability condition". Keywords that apply to all
|
||||
bugs could be separated from keywords that apply to a specific
|
||||
product, both on the global keyword list and the keyword list of a bug
|
||||
that is in that product.
|
||||
|
||||
We could specify groups of our own. For example, many keywords are in
|
||||
a mutually exclusive group, essentially like radio buttons in a user
|
||||
interface. This creates a natural grouping, although other groupings
|
||||
occur (which depends on your keywords).
|
||||
|
||||
It is possible that we could use collapsing/expanding operations on
|
||||
"twisties" to only should the groups we are interested in.
|
||||
|
||||
And instead of grouping keywords, we could order them on some metric
|
||||
of usefulness, such as:
|
||||
* when the keyword was last added to a bug
|
||||
* how many bugs the keyword is on
|
||||
* how many open bugs the keyword is on
|
||||
|
||||
Opting Out Of Keywords
|
||||
|
||||
Not all people are going to care about all keywords. Therefore it
|
||||
makes sense that you may wish to specify which keywords you are
|
||||
interested in, either on the bug page, or on notifications.
|
||||
|
||||
Other keywords will therefore not bother users who are not interested
|
||||
in them.
|
||||
|
||||
Keyword Security
|
||||
|
||||
Currently all keywords are available and editable to all people with
|
||||
edit bugs access. This situation is clearly suboptimal.
|
||||
|
||||
Although relying on good behaviour for people to not do what they
|
||||
shouldn't works reasonably well on the mozilla.org, it is better to
|
||||
enforce that behaviour - it can be breached through malice, accident
|
||||
or ignorance.
|
||||
|
||||
And in the situation where it is desirable for the presence or absence
|
||||
of a keyword not to be revealed, organisations either need to be
|
||||
content with the divulgence, or not use keywords at all.
|
||||
|
||||
In the situation where they choose to divulge, introducing the ability
|
||||
to restrict who can see the keyword would also reduce keyword
|
||||
overload.
|
||||
|
||||
Personal Keywords
|
||||
|
||||
Keywords join together a set of bugs which would otherwise be
|
||||
unrelated in the bug system.
|
||||
|
||||
We allow users to store their own queries. However we don't allow
|
||||
them to store their own keywords on a bug. This reduces the
|
||||
usefulness of personal queries, since you cannot join a set of
|
||||
unrelated bugs together in a way that you wish. Lists of bug numbers
|
||||
can work, by they can only be used for small lists, and it is
|
||||
impossible to share a list between multiple queries.
|
||||
|
||||
Personal keywords are necessary to replace personal tracking bugs, as
|
||||
they would not pollute the keyword space. Indeed, on many
|
||||
installations this could remove some keywords out of the global
|
||||
keyword space.
|
||||
|
||||
In a similar vein and with similar effects, group keywords could be
|
||||
introduced that are only available to members of a specific group.
|
||||
|
||||
Keyword Restrictions
|
||||
|
||||
Keywords are not islands unto themselves. Along with their potential
|
||||
to be involved in the inter-field relationships mentioned earlier,
|
||||
keywords can also be related to other keywords.
|
||||
|
||||
Essentially, there are two possibilities:
|
||||
* a set of keywords are mutually exclusive
|
||||
* the presence of a keyword implies another keyword must be present
|
||||
|
||||
Introduction of the ability to specify these restrictions would have
|
||||
benefits.
|
||||
|
||||
If mutually exclusive keywords were present on a bug, their removal
|
||||
would fix up the database, as well as reducing the number of keywords
|
||||
on that bug.
|
||||
|
||||
In the situation where a keyword implies another keyword, there are
|
||||
two possiblities as to how to handle the situation.
|
||||
|
||||
The first is automatically add the keyword. This would fix up the
|
||||
database, but it would increase the number of keywords on a bug.
|
||||
|
||||
The second is to automatically remove the keyword, and alter queries
|
||||
so they pick up the first keyword as well as the removed keyword.
|
||||
This would fix up the database and reduce the number of keywords on a
|
||||
bug, but it might confuse users who don't see the keyword.
|
||||
Alternatively, the implied keywords could be listed separately.
|
||||
|
||||
Notifications
|
||||
|
||||
Every time a bug gets changed notifications get sent out to people
|
||||
letting them know about what changes have been made. This is a
|
||||
significant feature, and all sorts of questions can be raised, but
|
||||
they mainly boil down to when they should be sent and what they should
|
||||
look like.
|
||||
|
||||
Changes You're Interested In
|
||||
|
||||
As of version 2.12 users can specify what sort of changes they are
|
||||
interested in receiving notifications for. However, this is still
|
||||
limited. As yet there is no facility to specify which keywords you
|
||||
care about, and whether you care about changes to fields such as the
|
||||
QA contact changes.
|
||||
Furthermore, often an unnecessary comment will go along with a change,
|
||||
either because it is required, or the commenter is ignorant of how the
|
||||
new system works. While explaining why you did something is useful,
|
||||
merely commenting on what you did is not because that information is
|
||||
already accessible view "Bug Activity".
|
||||
|
||||
Because of this unnecessary comment, a lot of changes that would
|
||||
otherwise not generate notifications for certain people do so, because
|
||||
few people are willing to turn off comments. One way to deal with
|
||||
this problem is to allow people to specify that their comments are
|
||||
purely explanatory, and that anyone who is not interested in the
|
||||
change will not be interested in the comment.
|
||||
|
||||
Furthermore, one possible rationale for unnecessary comments is that
|
||||
the bug activity does not display on the normal page and hence it is
|
||||
difficult to cross reference comments and actions. Hence, it would be
|
||||
beneficial to be able to do this.
|
||||
|
||||
Bugs You're Watching
|
||||
|
||||
Currently to receive a notification about a bug you need to have your
|
||||
name on it. This is suboptimal because you need to know about a bug
|
||||
before you can receive notifications on it. Often you are interested
|
||||
in any bug with a field set to a specific value. For example, you
|
||||
might be interested in all bugs with a specific product, component or
|
||||
keyword.
|
||||
|
||||
If someone could automatically receive notifications about these bugs,
|
||||
it would make everyone's lives easier. Currently the default assignee
|
||||
and QA contact for a component will automatically receive
|
||||
notifications for
|
||||
|
||||
Question: This moves half way to a BCC.
|
||||
|
||||
Bulk Changes
|
||||
|
||||
A very useful feature of Bugzilla is the ability to perform an action
|
||||
on multiple bugs at once. However, this means that similar
|
||||
notifications are currently generated for each bug modified.
|
||||
|
||||
This can result in a torrent of notifications that can annoy.
|
||||
|
||||
Furthermore, since the bugs are all changed close to each other in
|
||||
time, it is easy for someone to mass delete all the notifications
|
||||
generated by a bulk change and miss an unrelated notification in the
|
||||
middle.
|
||||
|
||||
These factors can lead to a tendency for people to delay bulk changes,
|
||||
or avoid them entirely. This is suboptimal.
|
||||
|
||||
It would be better if a bulk change generated only one notification
|
||||
mail. This would vastly reduce the annoyance factor, and prevent
|
||||
accidental deletion of notifications.
|
||||
|
||||
One problem with this change is that some people separate out
|
||||
notifications using filtering. This means that they would no longer
|
||||
be match parts of a bulk change under different filtering rules.
|
||||
|
||||
One possibility to resolve this is to allow people to specify groups
|
||||
of bugs. All bugs within a group would go into the same
|
||||
notification. The filters could then distinguish the different bug
|
||||
groups.
|
||||
|
||||
In any case, it is likely there would need to be a transition period
|
||||
to allow people to alter their filters.
|
||||
|
||||
Nominations
|
||||
|
||||
?
|
||||
|
||||
Linking Bugzilla Installations
|
||||
|
||||
The first example of linking Bugzilla installations together has is
|
||||
the introduction of bug moving in version 2.12. However, it would be
|
||||
useful to be able to link installations in more ways.
|
||||
* Dependencies and other relationships between bugs in other
|
||||
installations. This is difficult because dependencies are
|
||||
synchronised on both bugs, so the installation that changes
|
||||
dependencies would need to communicate the new state to the other
|
||||
installation. It would also mean that relationships and
|
||||
notifications that refer to other bugs would need to communicate
|
||||
with the other installation.
|
||||
* References to bugs in other installations. Currently if you type
|
||||
"bug XXX" or "bug #XXX" where XXX is a number, you get an
|
||||
automatic hyperlink to that bug. It would be useful if you could
|
||||
say "YYY bug #XXX" where YYY is the name of another installation.
|
||||
|
||||
Retirement
|
||||
|
||||
?
|
||||
|
||||
Whiny Reports
|
||||
|
||||
?
|
||||
|
||||
Group Redesign
|
||||
|
||||
?
|
||||
|
||||
Hard Wrapping Comments
|
||||
|
||||
Currently Bugzilla "hard wraps" its comments to a specific line size,
|
||||
similar to E-Mail. This has various problems:
|
||||
* The way it currently works, wrapping is done in the browser at
|
||||
submission time using a non-standard HTML extension not supported
|
||||
by some (uncommon) browsers. These browsers generate comments
|
||||
that scroll off the right side of the screen.
|
||||
* Because comments are of fixed width, when you expand your browser
|
||||
window, the comments do not expand to fit available space.
|
||||
|
||||
It would be much better to move to a world of soft wrapping, where the
|
||||
browser wraps the text at display time, similar to a world processor.
|
||||
And as in a word processor, soft wrapping does not preclude the
|
||||
insertion of newlines.
|
||||
|
||||
Hard wrapping is too entrenched into text E-Mail to fix, but we can
|
||||
fix Bugzilla without causing any problems. The old content will still
|
||||
be wrapped too early, but at least new content will work.
|
||||
</literallayout>
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<!-- Keep this comment at the end of the file
|
||||
Local variables:
|
||||
mode: sgml
|
||||
sgml-always-quote-attributes:t
|
||||
sgml-auto-insert-required-elements:t
|
||||
sgml-balanced-tag-edit:t
|
||||
sgml-exposed-tags:nil
|
||||
sgml-general-insert-case:lower
|
||||
sgml-indent-data:t
|
||||
sgml-indent-step:2
|
||||
sgml-local-catalogs:nil
|
||||
sgml-local-ecat-files:nil
|
||||
sgml-minimize-attributes:nil
|
||||
sgml-namecase-general:t
|
||||
sgml-omittag:t
|
||||
sgml-parent-document:("Bugzilla-Guide.sgml" "book" "chapter")
|
||||
sgml-shorttag:t
|
||||
sgml-tag-region-if-active:t
|
||||
End:
|
||||
-->
|
||||
|
||||
@ -193,9 +193,6 @@ try to avoid clutter and feel free to waste space in the code to make it more re
|
||||
<!-- Integrating Bugzilla with Third-Party Tools -->
|
||||
&integration;
|
||||
|
||||
<!-- The Future of Bugzilla -->
|
||||
&future;
|
||||
|
||||
<!-- Major Bugzilla Variants -->
|
||||
&variants;
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user