Bug 126907 - remove "Future" section from guide.

2 files changed, 0 insertions, 622 deletions

diff --git a/docs/sgml/Bugzilla-Guide.sgml b/docs/sgml/Bugzilla-Guide.sgml
index 0f5817221..2ee495eff 100644
--- a/docs/sgml/Bugzilla-Guide.sgml
+++ b/docs/sgml/Bugzilla-Guide.sgml
@@ -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;
 
diff --git a/docs/sgml/future.sgml b/docs/sgml/future.sgml
deleted file mode 100644
index 242418be0..000000000
--- a/docs/sgml/future.sgml
+++ /dev/null
@@ -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 &amp; 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:
--->
-