merging
← Older revision
Revision as of 2016-11-15T13:15:42
Line 1:
Line 1:
−
{{TopMenu}}
+
#
REDIRECT
[[QA/How to Improve Bugzilla]]
−
{{Menu}}
+
−
{{Menu.QA}}
+
−
{{OrigLang|}}
+
−
+
−
{{maybe-outdated}}
+
−
+
−
Planned improvements will be done for the existing Bugzilla by contraction, TDF will pay some money for a developer who will do several improvements.
+
−
+
−
== We will get ==
+
−
+
−
=== 3. reporter invitations ===
+
−
Currently it's not yet defined how that will be done.
+
−
+
−
=== 4. getting useful extensions onboard ===
+
−
* '''Why''': Extension might extend Bugzilla's abilities , especially concerning useful statistics, for example Reviewers' activities, duplicated bugs (already available [https://bugs.documentfoundation.org/duplicates.cgi?sortby=count&maxrows=100&changedsince=90&product=LibreOffice here], but in a very poor make, can't show Component related Duplicates), additional tags, pickers, queries
+
−
* '''Examples''': Michael Meeks found some working on https://bugzilla.gnome.org/:
+
−
** [https://bugzilla.gnome.org/page.cgi?id=weekly-bug-summary.html Summary of bug activity for the last week.]
+
−
** [https://bugzilla.gnome.org/duplicates.cgi Frequently (and recently) duplicated bugs]
+
−
** We can think about [https://wiki.mozilla.org/Bugzilla:Addons
#
Server-side_Utilities Server-side Utilities], [http://www.mediawiki.org/wiki/Extension:BugSquish Extension:BugSquish], [http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports Extension:Bugzilla Reports] and others
+
−
* '''How''': Installation of Bugzilla Addons on Bugzilla server, for example
+
−
** [https://addons.mozilla.org/de/firefox/addon/bugzillajs/ BugzillaJS - Tweaks for Bugzilla]
+
−
** [http://bayoteers.org/blog/ BAM] looks great
+
−
* '''Related Bugs''':
+
−
<br>
+
−
We will need more concrete wishes ("Details") here within short time!:
+
−
<br>
+
−
<br>
+
−
+
−
==== Detail: Additional reports and statistics ====
+
−
* '''Why''': Currently several statistics are maintained outside Bugzilla, for example daily / monthly number of bugfixes as line chart. It would save a lot of time if we could get such timeline related charts directly from Bugzilla. I would like to be able to create line charts like "Rainerbielfeld's Master Bug reports, weekly average last 6 months, may be even from the scratch.
+
−
* '''Examples''':
+
−
** [https://errors.ubuntu.com/]
+
−
* '''How''': for example [http://bayoteers.org/blog/extensions/bam/ Bugzilla Automated Metrics]; [https://bugs.documentfoundation.org/chart.cgi Create New Data Sets based on queries?]
+
−
* '''Related Bugs''':
+
−
<br>
+
−
+
−
===== Ad hoc date related Charts and Tables for Actions =====
+
−
Currently only Bug numbers at a particular day can be shown in a [https://bugs.documentfoundation.org/chart.cgi?category=LibreOffice&subcategory=WWW&name=1896&select0=1&label0=All+Closed&line0=1897&select1=1&label1=All+Open&line1=1896>=1&labelgt=Grand+Total&datefrom=2010-09-01&dateto=2012-07-04&action-wrap=Chart+This+List chart] easily. Statistics concerning actions only can be created with long preparation for the future. We need the possibility to create charts concerning questions to the past, some examples
+
−
* Bug reports / User(s) per month user related
+
−
* Monthly bug fixes Component related
+
−
* Comments of a particular user per week
+
−
<br>
+
−
+
−
==== Possible Duplicates research ====
+
−
* '''Why''': Avoids bug reports although problem has already been reported
+
−
* '''Examples''':
+
−
** [https://issues.apache.org/ooo/]: When you file a bug a list with possible duplicates appears
+
−
* '''How''': [http://www.bugzilla.org/releases/4.0/release-notes.html#v40_feat_dup Install pre-requisites on Bugzilla server]. No Idea whether Bugzilla offers Component related DUP research without Extension, so it seems that will have to be done with extension.
+
−
* '''Related Bugs''':
+
−
+
−
=== 6. Other ===
+
−
+
−
==== Hide obsolete Version numbers for new Reports ====
+
−
* '''Why''': New reporters generally will report for their current version, so all the old Versions might be only worrying. But to define the Version with what the problem started the old Versions still will be required after the original report has been done.
+
−
* '''How''': Currently there will be a possibility to suppress old Versions in the guided forms of bugzilla.
+
−
+
−
+
−
==== Time shift reporter invitation for more contribution ====
+
−
* '''Why''': Reporters who used the Bugzilla Guided Forms (and so might be novices) should be invited to help to confirm bugs. But immediately after the report might be awkward, for example because the reporter still is angry because of the problem he had with LibreOffice. So a time shift seems appropriate, invitation should happen (for example) 1 week after the report or when the report has been confirmed of fixed.
+
−
* '''Examples''':
+
−
* '''How''': Might be done with 3 Items:
+
−
** Automated (daily cronjob)
+
−
*** Read E-Mail Addresses / Reporter names
+
−
*** Send E-mails
+
−
*** May be create Database "No second invitation".
+
−
** Currently not affecting Contracting?
+
−
+
−
==== Better Keywords ====
+
−
* '''Why''': Currently we cannot easily add keywords that only make sense for LibreOffice to fd.o bugzilla, while there are some keywords in fd.o bugzilla that make no sense for LibreOffice. As a workaround currently the status whiteboard is used as additional keyword space, with the minor problem that typos cannot be detected.
+
−
* '''Examples''':
[[QA/
BSA/BugReport Details|BugReport Details#Whiteboard]]
+
−
* '''
How
''': Simply create some new key words, if possible and necessary Product related (only LibO), following examples will have
to
be confirmed by developers
+
−
** Patch_Experimental
+
−
* '''Related Bugs''':
+
−
<br>
+
−
+
−
==== Appropriate Bugzilla Help ====
+
−
* '''Why''': Currently [https://bugs.documentfoundation.org/page.cgi?id=fields.html#status Bugzilla Status help] is for "New Workflow", where (for example) Status NEW does not exist. Currently there is no interest to change Workflow, and Help seems to be only available for new one.
+
−
* '''How''': Help of obsolete Version?
+
−
+
−
==== Search for existing user names ====
+
−
* '''Why''': If you want to assign the bug or add people into CC, you need to know the full E-mail address. Same E-mails are hard to memorize. Some people use more E-mail addresses and nobody knows which one is used in bugzilla. It would be great to somehow search list of existing bugzilla users.
+
−
* '''How''': Enable the [http://www.bugzilla.org/features/#nick-complete nick completion] feature or the [https://wiki.mozilla.org/Bugzilla:Addons#Bugzilla_Extensions AutoComplete extension]
+
−
* '''Examples''': This works well in [https://bugzilla.novell.com Novell bugzilla]
+
−
<br>
+
−
+
−
==== Show warning if users change version to a later one ====
+
−
* '''Why''': Unexperienced users often change Version wrongly (<[[QA/BSA/BugReport Details|BugReport Details#Version>)]] to a later version because they find out that a bug still exists in the latest LibO version. It costs time to change back to appropriate most early version where the but appeared
+
−
* '''How''': It seems that that can be done easily with some additional JavaScirpt in the pages.
+
−
* '''Related Bugs''': {{tdf|49168}}
+
−
+
−
===
Improve
MediaWiki Integration ===
+
−
* '''Why''':
+
−
** Want to use [http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports Better MediaWiki integration]
+
−
** Might be solved with Bundle from above:
+
−
*** Features for automated lists like on [[Development/EasyHacks/lists/by Difficulty|Development/Easy Hacks by Difficulty]] like strikethrough for fixed Bugs, additional fields, ...
+
−
* '''Examples''':
+
−
* '''How''':
+
−
* '''Related Bugs''':
+
−
+
−
== We will not get ==
+
−
+
−
=== Account related permissions ===
+
−
* '''Why''' we would have liked that: Bugzilla offers lots of flags and pickers what can be used for structuring workflow. But there is some abuse (everybody marks his favorite pet Bug as "blocker", ...), so that most of these features currently are disabled. The ability to set bug priorites should always be restricted to known QA/developers, and the ability to update the Version should be restricted except during initial reporting (users tend to set the Version to the latest version with the bug, while it should contain the oldest version with the bug).
+
−
* '''Examples''': https://bugzilla.mozilla.org/
+
−
* '''How''': [https://bugs.documentfoundation.org/docs/en/html/cust-change-permissions.html Docs], [http://bzr.mozilla.org/bmo/4.0/annotate/head:/extensions/BMO/Extension.pm#L369 Extension example (bugzilla.mozilla.org)]
+
−
* '''Related Bugs''':
+
−
+
−
More details coming soon
+
−
+
−
[[Category:QA]]
+
<td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: to