The Saturday immediately following this year’s Grace Hopper Conference, was the second annual Grace Hopper Open Source Day, the goal of which was to get women involved in Open Source through projects with “humanitarian” aspects. The GNOME Foundation generously sponsored my travel making it possible for me to co-lead a full day on GNOME Accessibility with Western New England University’s Dr. Heidi Ellis. While I didn’t get a head count, I am guessing we had around 15 participants in our group all eager to dive in and triage a bunch of bugs filed against Orca.
Yeah, I know, bug triaging doesn’t sound especially motivating or captivating, let alone something one would “dive in” and do. But this work was and is desperately needed: Unlike many other software tools, in which the bugs are typically in the tool itself and require no specialized knowledge to triage, what gets filed as an Orca bug might indeed be an Orca bug; then again, there’s a healthy chance it isn’t. For any given application being accessed by an Orca user, a bug hindering that access may be in:
- the application itself
- the toolkit(s) used by that application
- the accessibility implementation of the toolkit
- the bridge between that implementation and AT-SPI2
- speech-dispatcher or the speech synthesizer
- brltty, brlapi, or liblouis
Add in to the mix the fact that distros ship different versions and combinations of all of the above, sometimes even patching items to better suit their needs, and what seems like the simple task of “triage this Orca bug” can rapidly become complicated and murky. Consequently it is an area where I regularly lose quite a bit of time — time which could instead be spent actually developing Orca if only I had some bug triagers familiar with screen readers, and Orca, and Accerciser, and pyatspi, and AT-SPI2, and ….
So when the opportunity to run a project at Open Source Day presented itself, it was hard to pass up: Not only could we tackle some work that badly needed to be done, but I could train people who would then be capable of continuing to do this type of work after the event.
After the Day’s opening plenary, during which time our group’s participants quickly installed Virtual Box and imported the Fedora 18 Alpha VMs provided, I gave the participants an extreme crash course in GNOME Accessibility 101. Then it was time to GetStuffDone™. I was too busy to look at clocks, but I think everyone was working for around five hours. Many even ate lunch while working. It was like having clones — only legal and without any associated ethical concerns. 🙂 It was awesome. Towards the end of the day, I took an informal poll to see how many of the participants would be interested in forming an “Accessibility Division” of the GNOME Bugsquad. Five or six indicated they would participate in such an effort. Yay!! 🙂
Lastly, our facilitator Aravind Narayanan deserves some serious props, not to mention my extreme gratitude. Showing up and hitting the ground running on any accessibility-related task typically requires previous experience. So when I found out that our facilitator is an engineer on the Infrastructure team at Facebook working on backend distributed systems, my assumption was that he’d be smart but not able to serve as a co-lead for this project. I was wrong. Very, very wrong. Aravind was AWESOME, helping participants just as effectively as Heidi and I and contributing significantly to the project’s success. Next year if I am invited to Grace Hopper Open Source Day, I want Aravind on our team. The rest of the projects will simply have to find someone else. 😉 Thank you Aravind!!