Re: [orca-list] [Fwd: [gnome-love] GNOME and GHOP (Google Highly Open Participation)]

[Brian Cameron <Brian Cameron Sun COM>]

Willie:

> The main constraint we're working with is that the tasks need to be 
> relatively straightforward and very well defined.  So "pick an app" is 
> not really viable, nor is something like "fix all the audio woes in the 
> world".  For example, for the above, we'd need to specify exact 
> applications (e.g., gnome-panel, gnome-search-tool, nautilus, Evolution, 
> etc.).  For extra credit, the motivated and precocious high school 
> student could devise ways to automate testing.

Why not review some applications and pick one that has a fair number
of known issues?

Perhaps the goal of the project could be to not only fix the problems
with the application, but to write a "How To" document which explains
how to go about testing an application for accessibility and how to go
about fixing bugs found, using this program as an example case.

> The immediate benefits to our community are that we get better testing 
> coverage of GNOME accessibility.  The longer term benefits are that we 
> begin exposing tomorrow's professionals to accessibility issues, perhaps 
> fostering growth in an industry where accessibility professionals are so 
> hard to come by.

I'd say that if we put together a How To Guide, then the benefits would
be more clear documentation that can be shared with module owners to
show them how to go about finding and fixing common bugs.

So perhaps the best "pick an app" would be an application that exhibits
a reasonable variety of accessibility problems that aren't too complex
to fix.  In other words, the sorts of bugs that we would hope module
owners would be more proactive about testing for, catching, and fixing
without needing to get others involved.

> I'm curious about your thoughts on this.  If you think the above is 
> reasonable, let's pick some apps and write some tasks for students.

I'd recommend an application that isn't too complicated to build, and
I'd also avoid applications that have unique (or hard to build)
dependencies.  This just makes it easier to get people working and
building with the code.  Perhaps a simple standalone program like
gcalctool or file-roller or a game in gnome-games (assuming these
programs have a good cross-section of bugs to fix).

Brian