David/Willie:

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

If David is looking for a co-maintainer, then I'd say this should
be highlighted on the A11y GetInvolved Wiki.  No?

Brian


> 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
>> [email protected]
>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>>   
> 
> _______________________________________________
> gnome-accessibility-list mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

_______________________________________________
gnome-accessibility-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

Reply via email to