Fwd: REST APIs, and Tags

[Max Kanat-Alexander]

On 02/10/2010 07:21 AM, Benjamin Smedberg wrote:
> I was just made aware of this thread, and wanted to post my thoughts and
> experiences from using the google code bugtracker.
> [snip]

	I've used it too, and I think it's very nice for setting up small
projects. The problem at Mozilla is that Firefox and the other major
products are enormous projects, and with an enormous project comes a
much higher required level of control and organization. Even Bugzilla
itself is a project larger than the vast majority of Google Code projects.

	The purpose of a bug tracker is, basically, to help people store and
organize bug reports.

	I suspect (though I don't know) that the Go and Chromium teams may be
finding that what the Google Code issue tracker currently offers isn't
enough to store and organize bug reports well-enough for a large project
with a certain number of contributors. Or maybe they have enough of a
paid triage team to cope with the organizational problems that the
system is causing.

	The approach that Bugzilla takes is that having a large, fixed UI is
actually more efficient for experienced users, because it allows them to
make changes and see information quickly. It is sometimes overwhelming
for new users, but to some degree or another that's OK if it helps new
users file better bug reports, and discourages the filing of unfixable
bug reports. The filing of poor bug reports and organizing the massive
influx are far more significant problems in a very large open source
project than the simplicity of using the bug-tracker, though simplicity
can and should still be worked for.

	Here's what I think is the best way to have discussions about Bugzilla:

	1) Set out some goal that applies to the current userbase.
	2) Determine the best way to meet that goal as an overall architectural
plan.

	#1 I usually like to think of as being phrased as a particular problem.
The more overarching (but specific) the problem's statement, usually the
better we can look at how to fix it. If it's too general or too
nitpicky, then we just get into the details instead of the architecture.

	If the goal applies to only one part of the userbase, then

	For #2, I think that Benjamin's suggestion here is a great
example--this is an overall architectural suggestion that would move
things in some different direction.

	Unfortunately, I think that this particular architecture, as an
underlying system for all of Bugzilla, wouldn't meet the goals of our
current userbase. It might be useful in a more limited sense as a
tagging system, but if we limit it to that, then we have to ask
ourselves "why not just use keywords?". Well, one response to that is,
"Because this allows a field-like organization of data." Then if we have
both fixed fields and tags, we get into a confusion of "when should I
use fixed fields, and when should I use tags?" which, architecturally
from a backend perspective, tends to lead us to always using tags. The
reason that I don't want to do that is that it requires a knowledge of
what the tag names are and what all their values are (which is not very
good for a huge distributed team that includes novice bug reporters and
triagers), as opposed to fields, which just show up automatically and
have all their values displayed.

	My general philosophy on major architectural changes is this:

	Bugzilla works. It may be something that people complain about, but
currently, it mostly does its job. The areas where it *doesn't* do its
job are what we should focus on, stated as specific problems in the form
of "Bugzilla is preventing me from storing and organizing bug reports
because...". Then we can come up with various ways to deal with those
specific problems until we find one that we think is most ideal, and
implement that most-ideal solution. (Note that often, "most ideal" means
"is flexible enough to handle the needs of our varying userbase".)

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.