Re: Bug triage

[David Bolter <dtb gnome org>]

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
>