[orca-list] How you can help

[Joanmarie Diggs <joanmarie diggs gmail com>]

Hey all.

Off and on over the past few weeks there have been threads on how one
can contribute to Orca. For those of you with the time and interest who
are not quite ready to dive into scripting, but want to eventually be
ready to do so, I have a proposal:

Pick your favorite app (e.g. Firefox, OpenOffice, whatever). Set up an
environment in which the only variable is that app, and where you can
have multiple versions of that app co-existing simultaneously. Then use
the most bleeding-edge version of that app as often as you can.

When something breaks, do the following:

1. Identify as precisely as possible the version/build where things
broke. The closer you can get to an exact date and/or build the better.

2. Having found the first version/build that is broken (say, Firefox 3.6
from 15 September), reproduce the problem while capturing a full
debug.out. (See http://live.gnome.org/Orca/Debugging for more info.)

3. Perform the very same steps, commands etc. in the last version/build
that is not broken (e.g. Firefox 3.6 from 14 September), also capturing
a full debug.out.

4. Compare the two debug.outs. They should be awfully similar because
the only thing that's different is your favorite app, and you've taken
the time to find the exact version of that app where things changed. So
find out what happened: Look for events that are missing. Look for new
events. Etc.

5. Take all of the above data along with your analysis of it and file a
bug against the appropriate component. That might be Orca; it might be
the app you were testing.

6. As you develop strategies for quickly pinpointing a problem, add it
to the wiki so other community members can join in this effort.

Currently, I spend a lot of time doing the above in response to
something said on list and/or a vague bug filed. In fact, I suspect I
spend far more time doing the above than I do fixing the problem -- or
reporting the problem to the developers who need to fix it when the bug
is not within Orca. If you all can identify the precise point when
something broke *and* identify what exactly changed (e.g. the
new/different at-spi event), it would help the Orca team out
tremendously.

Beyond helping the team out, I can tell you personally that once you've
stared at enough debug.out files a lot will become clear. It does take a
while. And you may have moments along the way where you think, "Joanie
must be nuts, this stuff makes no sense." But trust me: You'll start to
get it, because you'll see what Orca is reacting to and how it's
reacting to it. From there, you can start modifying the code where
Orca's doing that reacting and see what changes as a direct result of
your modification. This process will expose you to Python and the
general coding style and conventions used within Orca. And once you've
got that down, you'll be able to start fixing bugs and ultimately
writing scripts, at which point I am *so* going on vacation. <grin>

All kidding aside, the process I've described above is how I got to the
where I'm at now. And if I can do it, you can do it.

Take care.
--joanie