Improve handling of bug reports for GTK+?

[Andre Klapper <ak-47 gmx net>]

[Please CC me on answers as I am not subscribed ot this list.]

The situation of GTK+ in bugzilla.gnome.org: 
High number of open tickets, high number of unreviewed patches,
constantly growing number of tickets, no real triaging of reports.

Feedback, please: I'd like to know how you (GTK+ developers/maintainers)
handle GTK+ bugmail and work in Bugzilla.
Do you read gtk+ bugmail at all? Does it scale? Is it too noisy?

A first proposal (please tell me if it makes sense):
https://bugzilla.gnome.org/describecomponents.cgi?product=gtk%2B lists
for most components the default assignee "gtk-bugs gtk org".
In case you are only interested in following specific areas of the GTK+
codebase (is that the case?), would it make sense to have one default
assignees per one component (for example introducing
gtk-gtkapplication-maint gnome bugs for GtkApplication, and likewise)?

Are there components missing? Which ones? It feels like lots of stuff is
dumped under "general" that does not find a better home because there
are no Bugzilla components for some of the newer widgets.

So, how would Bugzilla work better for you?
(I'd also happy to discuss this in a GTK+ meeting, but
https://live.gnome.org/GTK+/Meetings lists the next meeting for 15
months ago.)

andre
-- 
mailto:ak-47 gmx net | failed
http://blogs.gnome.org/aklapper