The future of Bugzilla is Bugzilla 3.0. Unfortunately, I do - not have more information about it right now, and most of what - went into the "future" section is now present. That stuff was - blue-sky a year ago; MattyT should have me a new document - sometime... +> Bugzilla's future is a constantly-changing thing, as various developers + "scratch an itch" 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. +
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.
+