Fwd: REST APIs, and Tags

[Gervase Markham]

Here are David Ascher's thoughts on tagging and Bugzilla usability,
which I thought might be good food for thought. (He gave them to me in
the context of the REST API.)

I definitely think that over the ten+ years of Bugzilla's life, we've
had about five goes at the "tag" thing (status whiteboard, keywords,
flags, saved searches, and now the tag system in the footer) and each
time we've missed the simplicity and ease of what seems to have evolved
as the standard way to set and search for tags (a freeform,
comma-separated list anyone can search on a la Flickr and del.icio.us).
keywords are too bondage-and-discipline and centrally controlled, the
whiteboard is too freeform and is a (slower) text search, and the footer
tag system seems really complicated in its UI and hard to share with others.

It would be great to start a discussion on our future plans for this 
sort of thing. For example, can we merge keywords and what we now call 
tags into one tag implementation (incorporating both public and private 
tags) which has these desirable properties?

Gerv

-------- Original Message --------
Subject: REST APIs, and Tags
Date: Thu, 02 Jul 2009 15:17:56 -0700
From: David Ascher <dascher at mozillamessaging.com>
To: Gervase Markham <gerv at mozilla.org>
CC: Mark Surman <mark at mozillafoundation.org>,  Dan Mosedale
<dmose at mozilla.org>, Aza Raskin <araskin at mozilla.com>

In both of these areas, I think that Flickr has set a role model that's
worthy of emulation:

http://www.flickr.com/services/api/

(with some humor even:
http://www.flickr.com/services/api/misc.encoding.html)

see e.g. http://www.flickr.com/services/api/flickr.favorites.add.html

and the explorer tool:
http://www.flickr.com/services/api/explore/?method=flickr.favorites.add


The key bits here is that by looking at these pages, people can
understand the API model for flickr w/o having to dig any deeper.  The
RESTful thing makes it easier to approach than an RPC-model, easier to
see how it could scale, etc.

---

On tags, the usual challenge is how to give people structure (e.g.
official milestones, operating systems) that is needed for aggregation
queries ('show me all mac blockers'), while decentralizing the locus of
that structure, so that different groups can come up with different
structures.  It's also critical to distinguish the
structure-by-convention from the structure-imposed-by-the-database.  In
particular, one could argue that bugzilla should just have one "tags"
field for a bug, but let different bits of the UI rely on different
"schemas" for tags.

You asked for problems w/ the current scheme:

1) there's no rationale for whether something goes in the status
whiteboard or a keyword, except that keywords are tightly controlled and
some bizarre, frozen-in-time list which which mostly doesn't change
because it applies to _all products_, and status whiteboard is
freeform-but-laden-with-conventions.

2) user tags are too hard to share, hence pointless IMO -- tags worked
in flickr and delicious because they became fast and easy ways to share
sets of URIs.  In Bugzilla, it's the horrible thing called a saved
search, which is way, way too hard to work with, and requires that
people be logged in for no good reasons.  If I could just post
http://bugs.mozilla.org/bugs/davidascher/tags/tb3+student_project to the
world, i'd be much happier.

I can imagine a version of bugzilla with a tags field which on disk
looked like one big json blob which encoded components, products,
milestones, keywords, status whiteboard.  (per-user tags probably don't
belong on the same table).  A lot of the current _structure_ of each bug
is not particularly useful per se, and could be implemented with
rss/atom feeds on tag-based searches.

Let me give an example -- in a previous version of the ActiveState
bugzilla DB, we "suffered" from the problem that each product team had a
different culture, a different way of dealing w/ QA, regressions, bug
triaging, etc.  The Komodo team wanted to use "tags" like "on-radar",
"off-radar", but the Perl team didn't.  Bugzilla didn't allow for the
right kind of per-product separation, so we put those distinctions
strictly in the UI, and from the DB's point of view we just used the
status whiteboard field.

-david
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla