Re: Commit fest queue

On Sat, Apr 12, 2008 at 3:46 AM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> As an aside, you've reminded me about another thing that bothers me about
> Bugzilla and RT. In both cases they seem to put a lot of focus around the idea
> of "searching" bugs. I don't really get why.
>

Er, because pretty much everybody wants the ability to easily consult
the project's development history?

In a typical bugzilla scenario, the majority of users are going to be
accessing the tracker either to file a bug or request a feature.
Search must be front and centre for this to work effectively, because
you want those users to search for similar bugs before creating a new
one.

Trac's UI is less focussed on search. The search box just sits up
there in the upper right corner in case you want to use it.

> I would think an interface which presents you with *all* unclosed bugs by
> default, perhaps organized in some way (keywords, milestones, etc) would be
> more conducive to getting attention to everything.
>
> I'm sure you can do something like that in Bugzilla and RT but it sure doesn't
> seem to be the way it's used in practice.

Yes, of course all reasonable trackers also have a way to pull up
complete listings of open items.

I think you've been thrown off the scent because bugzilla's primary UI
is geared towards the submitter's usage pattern, not the reviewer's.
It doesn't mean that the reviewer is left out in the cold. It does
mean that, as a reviewer, you have to either place an extra click or
two to bring up your favourite listing, or (!) make a bookmark.

For example, in Trac you click on "View Tickets" and then "Active
Tickets". It's a two click operation. It's not like it's obfuscated.

Cheers,
BJ