On Sat, Apr 12, 2008 at 3:46 AM, Gregory Stark <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
