This page describes some of the underlying core principles that we use to develop Bugzilla.

The Purpose of Bugzilla

The purpose of Bugzilla is:

To help people store and organize bug reports.

Without limiting the above statement, here are some examples of what we mean by "storing and organizing":

• Storing includes filing, viewing, and editing bugs.
• "Organizing" generally means "putting order into a large number of bug reports". It includes:
  • Having a system of organization for bugs that allows them to be located. In Bugzilla, this is mostly accomplished by the various bug fields. (This is the purpose of bug fields.)
  • Having a search system that allows finding what you're looking for (or being told that it's not in the system, if it's not in the system).
  • The ability to sort lists of bugs according to the user's needs, such as "what order should these bugs be fixed in?"

Our General Principles

• It is more important to make Bugzilla helpful to experienced users than it is to make it simple. (However, simplicity should still be a goal whenever it doesn't interfere with being helpful to experienced users.)
• Discourage the filing of unfixable bug reports, without discouraging the filing of fixable bug reports.
• Bugzilla is a bug-tracker, not a Project Management system.
• Bugs should be very fast to edit for people who edit bugs. We mean fast in terms of the total time the user spends editing them, not just in terms of the system's performance.
• Searching should be powerful, flexible, and fast.
• Comments are an immutable historical record of what was said on a bug.
• Bugzilla needs to work for both closed in-house development shops and public bug-tracking of open-source projects.

Having Productive Discussions About Bugzilla

To have a productive discussion about what we should be doing with Bugzilla in terms of features, probably the best way to go about it is:

1. Set out some goal that applies to the current userbase.
2. Determine the best way to meet that goal as a well-thought-out general plan that involves incremental changes.

The "goal" from Step 1 can usually be thought of in terms of "What problem are we trying to solve?" The best way to phrase a problem is probably "Bugzilla is preventing me from effectively storing and organizing bug reports because...". The problem should be a real one, that people are actually experiencing.

Once the problem has been phrased, then we can sensibly determine a way to go about handling it. Generally, the statement of the problem should come first, and then solutions should be provided afterward.