Modifying workflow

Primary focus in current workflow

1. Create/modify ARIA features
2. Determine platform mappings
3. Enter CR
4. Write all test files
5. Conduct all testing
6. File bugs against user agents for missing/incorrect implementations
7. Enter PR when we've met CR exit criteria (assuming we don't have to exit and re-enter CR)

Primary focus in proposed workflow

1. Create/modify a single ARIA feature
2. Obtain platform mappings for that feature from platform mapping maintainers
3. Create* test file(s) for that feature and add to web-platform-tests
4. Create test results for that feature and add to test-results
5. File bugs against user agents for that feature
6. Solicit assistive technology implementations for that feature
7. Write authoring guidance for that feature
8. Should we enter CR (e.g. all in-scope features completed; or at target milestone deadline)? If not, go to step 1.
9. Enter CR with all features that are "ready"*
10. Enter PR after approximately 60 days (assuming we don't have to exit and re-enter CR)

Thoughts on implementation details

"Single ARIA feature" workflow

• Does NOT mean we can't/won't work on multiple features at any given time
• DOES mean we want to be working on only a very small number of features at any given time
• MIGHT mean we adhere more closely to the Working Draft - Editor's Draft distinction, e.g.:
  • Working Drafts only contain what's "done" (successfully gone through workflow steps 1-6/7)
  • Editor's Drafts also contain our work-in-progress features

Create test file(s)" meaning

• Initially: "write it"
• In near(ish) future: "programmatically generate it from the specs"

Who does what?

• Joanie will write documentation and provide assistance/training for members who need it.
• The creator/modifier of the feature does steps 1-6 (Joanie's preference), OR
• Specific members focus on specific step(s)

Possible criteria for "readiness" of a feature

• Positive confirmation of acceptance by a sufficient* number of user agent implementors in the form of a passing test result or a comment in a public issue tracker that they intend to implement as described in the spec(s).
• Positive confirmation of acceptance by multiple assistive technology vendors in the form of implementing support, or a comment in a public issue tracker that they intend to implement support.
• Confirmation by the Authoring Practices task force that there are no unanticipated problems with the feature.

"Sufficient" will depend on the anticipated exit criteria of the associated spec(s).

Addressing consequences of current workflow

(See the ARIA 1.1 Post-Mortem)

Disconnect between what we want and what implementors want discovered after entering CR

Addressed by:

• Obtaining platform mappings for each feature from platform mapping maintainers before entering CR
• Filing bugs against user agents for each feature before entering CR
• Obtaining test results for each feature before entering CR
• Soliciting assitive technology implementations for each feature before entering CR
• Only including features which we have determined meet our criteria for "readiness"

Critical bugs blocking implementation discovered after entering CR

Impact minimized by:

• Only including features which we have determined meet our criteria for "readiness"

Errors in AAM discovered after entering CR

Addressed by:

• Obtaining platform mappings for each feature from platform mapping maintainers before entering CR
• Filing bugs against user agents for each feature before entering CR
• Obtaining test results for each feature before entering CR

Platform owners cannot make changes in mappings without risking exiting CR

Addressed by:

• NOT addressed changes to workflow
• For ARIA, might be addressable by not using AAM as the means to test implementability
• For AAMs, might be addressable by treating AAMs as non-static specs

Milestones slipped multiple times

Addressed by:

• Considering target milestone deadlines as a (possibly) valid reason to enter CR
• Always being ready to ship

Many Working Group members unable to contribute after Workflow step 1

Addressed by:

• Programmatically generating tests and test results for each feature
• Providing documentation and assistance/training for members who need it