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=1524738>under 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
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
