Re: How to handle bugzilla

[John Fleck <jfleck inkstain net>]

On Wed, Apr 23, 2003 at 12:06:56PM -0400, Alexander Larsson wrote:
> I have a problem handling the Nautilus bugzilla emails. Given that I
> have a lot of stuff to do, and that I have to actually hack on
> Nautilus also there is just no way I can keep up with the spew from
> nautilus-maint.
> 
> To give a sense for the proportions here, let me give some stats.
> My nautilus-bugzilla folder has 17886 emails in it from the start
> March 1, 2002. Thats an average of 42.6 bugzilla emails a day for
> nautilus and eel. In addition to this I need to follow gnome-vfs and
> get CCd on various other bugzilla reports. (Plus I have to follow
> redhat bugzilla, including the Nautilus module there.)
> 
> The problem is, if I can't read all the mail, there is a large risk of
> both dave and me missing important bugzilla mail, like patches or
> important information.
> 
> Since Nautilus is a very user-visible package we get a lot of
> user-level bugreports, a lot are dups, a lot are crap, some are really
> for other packages, and a lot are just random ideas that people
> have. We have a very active group of bug-squad people managing these
> bugs, which is *very* nice, and helps a lot. 
> 
> However, all these new bugs and changes cause a lot of traffic on the
> nautilus-maint list, increasing the risk of something important
> getting lost. Does anyone have any ideas how this could be improved?
> Maybe some way to filter the mail based on keywords or something?
> Maybe if all new bugs go to a "normal" folder, or gets marked in some
> way, and then when I, the bug squad or someone looks at it and sees
> it's important it gets put in the "important bugs" folder so that I
> will read them first.
> 
> Any other ideas how to handle this?
> 

Having spent some time on the nautilus-qa alias, I feel your pain.

What Nautilus needs, probably more than any other application, is a
QA/bugsquad person who is working closely with you and Dave doing triage,
someone who understands the development process well enough to elevate bugs to
your attention so you don't have to look at every single change in every
single bug.

The technical details on how to flag those elevated bugs (keywords, milestone
targets, bug assignment email, carrier pigeon messages or whatever) are less
important than the need for a human in that loop to do the elevating so you
and Dave are only looking at bugs that matter (however that might be defined)
and can ignore the rest.

Cheers,
John