Accessibility/Meetings/2012-05-02

From MozillaWiki
Jump to: navigation, search
  • Q2 goals status
  • Priorities:
    • Mac: Performance, feedback
    • Mobile: More AccessFu work, B2G
  • Fun ;-)

Notes

Goals

  • NO PROGRESS - Increase performance by 30% for Speech Recognition use cases.
  • SOME PROGRESS - Have usable mozbase platform automated tests.
  • SOME PROGRESS - Get Android a11y into a release channel.
  • NO PROGRESS - Have a working prototype of a B2G screen reader.
  • NO PROGRESS - Have an alpha version of a mobile gesture addon.
  • SOME PROGRESS - Bring OSX Firefox a11y on par with Win/Linux

NOTE: The android a11y is encountering lengthy review cycles (leading to patch review discussion below). This puts 3 goals in jeopardy (android, b2g, gestures) and is something we need to fix.

Patch Review

We discussed how to speed up our review cycle:

  • New vs Existing. We observed that new feature work (for new users) can have a different standard of requirements than changes to existing code (with users). Specifically, in order to get features into the hands of users we need to land stuff that works and is good and block only if necessary. So strive for an r+ if the patch is decent and doesn't break things, file follow ups, ask for QA, get back the follow ups later. With existing/legacy code our bar is higher and we can be meticulous as time permits. The goal of getting to the perfect patch is well intended and more practical here.
  • We noted that there are different rates of development for different teams or features and that this probably directly relates to the 'new vs existing' distinction.
  • Strive for a minimum of 24 hour turn around time on questions and answers in bugs.
  • We noted that the bar for bug fixing might be quite different for different teams.