Re: [orca-list] Draft Proposed Two-Year Roadmap

[Joanmarie Diggs <joanied gnome org>]

Hey Peter.

Regarding this:

> For example, the roadmap puts "Improved Access to Gecko-Based
> Applications" July 2011-October 2012.  How well does that line up with
> what the Gecko folks will be doing at that time (to best ensure those
> hackers will be available to collaborate, and perhaps fix issues that
> are really theirs)?  Likewise with "Improved access to OpenOffice" in
> July 2011-July 2012.  I suggest that maximizing synergy with external
> groups should have a strong influence on what you guys focus on when,
> and that you strive to be somewhat flexible as those schedules become
> known (if they aren't yet known) or as they change (which may happen
> given how software engineering works...).

Totally agreed. As Ale indicated in his response:

1. It is a draft and the dates are subject to change as the community 
   considers this proposal.

2. I am pleased to say we're once again working quite closely (read,
   tend to interact more or less daily) with the Mozilla a11y
   developers.

In addition, the proposed dates, especially those for work related to
Orca + OpenOffice, take into account:

1. Whether or not the Orca team has triaged the issues from the Orca
   side of things. In many cases we already have. Early triage for OOo
   is something we got into the habit of doing... gosh... at least a
   couple of years ago because we realized that the OOo and GNOME cycles
   just don't line up all that well. Thus we try to ask the OOo team
   for the things we'll anticipate needing six months to a year down
   the road.

2. Whether or not the OOo a11y team has already done the work on their
   end necessary for us to do what we need to on our end. In many cases
   they have because of our pre-planning and bug/rfe filing.

3. Whether or not the Orca team and the OOo a11y team need to sit down
   and talk about what should be done on each side before either can
   begin work. Charts and graphs come to mind.

4. Potential changes to Orca's architecture and whether or not such 
   changes might make it more prudent to postpone an implementation
   because that would, in the long run, be more productive than doing
   and then subsequently redoing the implementation in question.

5. Murphy's Law. Just when we think we can sit down to tackle an issue,
   something else more pressing comes up demanding our attention.

All a long way of saying that we did everything we could in this initial
proposal to incorporate what we have learned over the years about the
teams with which we work: their processes and ours, their release cycles
and ours, their staffing levels and ours. And then built in some extra
"wiggle room" to be on the safe side.

However, having said all of that, if you have specific changes that you
would like to see made, by all means let us (Orca team + User community)
know and let's discuss.

Thanks for the feedback! Take care.
--joanie