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