diff options
Diffstat (limited to 'docs/sgml/future.sgml')
| -rw-r--r-- | docs/sgml/future.sgml | 595 |
1 files changed, 590 insertions, 5 deletions
diff --git a/docs/sgml/future.sgml b/docs/sgml/future.sgml index 1f4681a31..54f191349 100644 --- a/docs/sgml/future.sgml +++ b/docs/sgml/future.sgml @@ -4,11 +4,595 @@ <title>The Future of Bugzilla</title> <synopsis>Bugzilla's Future. Much of this is the present, now.</synopsis> <para> - 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 + <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> @@ -32,3 +616,4 @@ sgml-shorttag:t sgml-tag-region-if-active:t End: --> + |