On Fri, 2012-02-10 at 12:23 +0100, Andre Klapper wrote: > Hi GNOME documentation team, > hi bugsquad in CC, > > Describing the current situation of bug reports about user documentation > issues: > > * Some products in GNOME Bugzilla have a "docs", "Documentation", > or "User Guide" component > * Most of these components have the (virtual) default assignee > [email protected] > * Half of the products with [email protected] > as "Default Assignee" also have it as "Default QA Contact", > half of them doesn't. > Not a big issue but it makes those reports not easily > watchable for module maintainers as they would have to > follow all of gnome-user-docs-maint@'s bugmail.
I think my original proposal was something like this: * If the docs team at large owns it, set gnome-user-docs-maint as the default assignee. Set the default QA contact to whatever you want, possibly your own -maint alias so you can watch the bugs. * If somebody on your team owns it, but you still want the docs team involved, use something for default assignee, but set the default QA contact to gnome-user-docs-maint. > * Some "docs" components have the default assignee shaunm: > GGV, gpdf, zenity > I'd like to change that to gnome-user-docs-maint@ if Shaun is > fine with that. > * Of these, some "docs" components have Shaun also as Default > QA contact shaunm (which makes those reports not easily > watchable for module maintainers as they would have to > follow all of Shaun's bugmail): > gpdf, zenity This should basically never, ever, ever happen. Any component where I'm the default anything should be changed to one of gnome-user-docs-maint, gnome-devel-docs-maint, or yelp-maint. Those things probably predate -maint aliases, and they slipped through the cracks. > * Some products have NO "docs" component (e.g. brasero). Reports > require manual reassigning to [email protected] . > It is likely that this does not always work perfectly. ;-) These should be fixed. > * There is a "documentation" keyword that is used broadly (mostly > for developer docs?) with 157 open reports: > https://bugzilla.gnome.org/buglist.cgi?resolution=---&keywords=documentation And I never use the documentation keyword. > * There might be something else that I have forgotten and that > you can add here. > > > Documentation team members: > Do you look at documentation bug reports? Is it easy enough to find them > (either for your product only, or in general)? Do you e.g. use > https://bugzilla.gnome.org/page.cgi?id=describeuser.html&[email protected] > > or > https://bugzilla.gnome.org/buglist.cgi?emailassigned_to1=1;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;email1=gnome-user-docs-maint%40gnome.bugs;emailtype1=substring > > for that? > If you don't look at them, even better: Why not? Any ideas how to make > things easier and better for you? When I'm working on something, I look specifically at the bugs for that product/component. If I'm working on the Empathy help, then I'm looking at this URL: https://bugzilla.gnome.org/buglist.cgi?product=empathy&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=User%20Guide But I do look at the list of bugs for the -maint aliases to get a sense of things I could be working on (or making other people work on). -- Shaun _______________________________________________ gnome-doc-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-doc-list
