Re: Bug triage



If someone wants to take a crack at triaging the GOK bugs please do help! I'm still on "holiday", but will try my best to find time to work with someone to prioritize GOK bugs. It may turn out that we (GNOMErs) focus efforts on a new OSK, but even in that case it would be good to keep GOK viable for it's users in the meantime.

I'm also looking for a co-maintainer and am happy to mentor.

cheers,
David
Willie Walker wrote:
Hi All:

The current list of bugs with the 'accessibility' keyword can be found via the following search (this is the same link under the "Help Fix Bugs" header on http://live.gnome.org/Accessibility/GetInvolved):

<http://bugzilla.gnome.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=accessibility&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&field0-0-0=noop&type0-0-0=noop&value0-0-0=&query_based_on=&order=bugs.priority,bugs.bug_severity,bugs.bug_id&query_based_on=>

Omitting the Orca bugs, which the Orca team constantly triages, there are 381 bugs that we need help with. What I think we need to do are:

1) Verify the bugs still exist -- some may be obsolete at this point. If the bugs still exist, help make sure there is a clear test case for reproducing the bug. Developers like clear test cases - the lack of clear test cases is sometimes the reason bugs languish for so long.

2) Helping to identify the ones that would have the most impact if fixed. Ideally the priority (http://bugzilla.gnome.org/page.cgi?id=bug-status.html#priority) and severity (http://bugzilla.gnome.org/page.cgi?id=bug-status.html#bug_severity) fields would help make this list somewhat self sorting. When changing priority and severity, I read the definitions for the various values and then I tend to provide a reason for why I made a change. For example, I might say "marking this bug as Major because not being able to access the main window is a major loss of functionality that makes this application difficult/useless to use by people with disabilities" or "marking this as minor, because even if the given button doesn't work, accessing the same functionality via a menu item provides a reasonable and efficient workaround." I also try not to "cry wolf" or take some stance such as "all a11y bugs are immediate blockers". Be true to the meanings provided and the really important problems will bubble up.

I also tend to view the priority and severity as applying to just the product in question. That is, what is the priority/severity of this bug on just the product, not the whole of GNOME? I'm not sure that's the right way to do things -- if it's wrong, someone please correct me. :-)

Any takers to help with triaging?

Will
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list



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