- From: White, Jason J <jjwhite@ets.org>
- Date: Thu, 6 Oct 2016 14:50:00 +0000
- To: Alastair Campbell <acampbell@nomensa.com>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
- Message-ID: <BY2PR0701MB19900821256E0F6E02D0C979ABC70@BY2PR0701MB1990.namprd07.prod.outlook.>
From: Alastair Campbell [mailto:acampbell@nomensa.com] Sent: Thursday, October 6, 2016 10:28 AM There is an implicit assumption in the 2.1 approach that might not be obvious to people who haven’t been involved in Agile projects in the last few years. I could also be wrong that this is an assumption, so let’s make it explicit. Apologies to everyone very familiar with Agile, but for everyone else: the assumption is that you fit the work into a time-box, and release what is done in that time. If there are only 3 new SC that get consensus by the deadline, then 2.1 may have only 3 new SC. Given the time between 2.0 and 2.1, I think we can manage a lot more than 3, but that is an assumption of the process. (I appreciate that the guidelines need to work as a whole, so we should also get consensus on the whole at each dot release, not just the individual SCs.) The rest of the W3C appears to be working in this way, I suspect we need a very good case not to follow suit. [Jason] I’m not convinced that agile processes will work for WCAG, given the need for high-quality, long lasting requirements and the very substantial effects of this work on the regulatory environment. I think it’s a sufficiently attractive proposal that it should be tried in version 2.1 by initiating a schedule-based release process, however, with a review thereafter to decide whether to proceed with a further 2.x release or whether the remaining proposals should go directly into the next major revision. In effect, I favor postponing any decision about “agile” until the completion of WCAG 2.1. If it’s successful and yields general satisfaction, then the Working Group can request a new Charter either to complete Silver or to continue to develop Silver and (in parallel) to deliver a 2.2 version. If there are problem with the 2.1 process, the next steps can be decided accordingly, with the benefit of experience rather than assumptions and hopes (which are all we have now). I don’t support using a re-chartering opportunity to assert a long-term process direction in circumstances in which the proposed process hasn’t been shown to work in the special case of WCAG, which is very different from a typical W3C technical specification in salient respects. My proposal does not change the scope of the work that would actually be completed under the draft Charter; it merely removes the signals that would indicate an intention to commit to agile development prior to having experienced what happens to version 2.1. ________________________________ This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ________________________________
Received on Thursday, 6 October 2016 14:50:33 UTC