Re: Handling bug reports on user documentation
- From: Shaun McCance <shaunm gnome org>
- To: Andre Klapper <ak-47 gmx net>
- Cc: gnome-bugsquad <gnome-bugsquad gnome org>, GNOME Documentation <gnome-doc-list gnome org>
- Subject: Re: Handling bug reports on user documentation
- Date: Fri, 10 Feb 2012 15:52:49 -0500
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]