Hey Folks,

the bug type field sounds interesting, if you want this for Thunderbird
it is just a bug and a deployment away.

Philipp

-------- Forwarded Message --------
Subject: Improving our usage of Bugzilla
Date: Tue, 12 Mar 2019 11:55:12 +0100
From: Sylvestre Ledru sylvestre@mozilla.com

Bugzilla is one of the key tools used for the development of Firefox
since the Netscape era. Even though this tool is serving us well, after
interviewing a bunch of people at every level inside the company, we
realized that we need to go the extra step.

Therefore, we decided to focus on improving Bugzilla itself but also, as
a next step, improve the workflows we have on bugs.

To start with, we are coming with a set of three major changes to make
our life better and easier.

1. Enforcing the usage of the priority field

As described in this schema
https://docs.google.com/drawings/d/1G8SV3EUPknh-2zExL08cd9lzzGMOHAZeRA1geBQnGD4/edit,
we are now asking triage owners to set the priority field according to
the priority definition
https://mozilla.github.io/bug-handling/triage-bugzilla#how-do-you-triage.
The main goal is to make sure that every bug has been looked at and a
priority has been set in accordance with the priority definitions.

A bot will automatically needinfo the triage owner (or a member of the
team if it uses a round robin triage method).

We have been experimenting with this for several components and the
results look great!

2. Bug type - new field

Firefox development requires a bug for every change in the Firefox code
base. It doesn’t matter if this is used to fix a defect in the product,
to implement a new feature or to refactor some code.

For years, we have been using bugzilla keywords to classify them.
However, as they are not mandatory, the metadata can be missing,
unmaintained, or inconsistent.

With this change, we are going to extend Bugzilla to add a new field
with three new values:

Defect - an issue in one of our products

Enhancement - a new feature or an improvement

Task - a developer task. For example: refactor code foo.

Since we don’t want to increase the confusion for new users, the default
value will be defectand, to the best of our ability, existing bugs will
be moved https://bugzilla.mozilla.org/show_bug.cgi?id=1524738under one
of these categories.

With this information, we will be able to more precisely measure the
quality of our products, as we will not mix defects together with
feature-related work.

We have a development instance of Bugzilla
https://bugzilla-dev.allizom.org/where the changes can be evaluated,
we are planning to go live in the new few weeks.

More information https://bugzilla.mozilla.org/1522340

3. Adding a new field called “Regressed by”

Currently, we misuse the blocks/depends fields to mark bugs causing
regressions. However, they can be confusing and aren’t used consistently
by developers. Moreover, since we are using bugs for defects,
enhancements or tasks, it can be very hard to pinpoint the changes which
introduced a regression.

Being able to pinpoint changes which introduced regressions will make it
easier to build tools to help with assessing the riskiness of changes.

Therefore, we will add a new field in bugzilla which will clearly
identify which bug caused a regression.

More:

http://bugzilla.mozilla.org/1461492

Last but not least, nothing is written in stone and we have other
improvements (bug workflow, improved search, regression field, etc)
coming. Sylvestre

I follow BMO tooling and so for a few weeks now I've been following the
activity leading up to this announce, and talking to the BMO team to
better understand how this might be adapted/adopted for Thunderbird bug
space.

I still have some questions but the structure and process seems sound,
and scaleable.  I am excited to discuss the possibilities with the team.

There is ongoing discussion mozilla.dev.platform newsgroup aka
dev-platform@lists.mozilla.org which is where Philipp pulled this
initial posting.