Brian, Yes. Excellent point, but I was waiting to see where the community thought we should spend energy in the OSK/alt-input space before making the request for a co-maintainer.
cheers, David Brian Cameron wrote: > 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 > _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
