Re: Handling bug reports on user documentation



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
>     gnome-user-docs-maint gnome bugs
>     * Half of the products with gnome-user-docs-maint gnome bugs 
>       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 gnome-user-docs-maint gnome bugs .
>   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&login=gnome-user-docs-maint gnome bugs 
> 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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]