Improving Web Standardization

Improving Web Standardization

1. Producing Specifications
2. Achieving Interoperability

Part 1:
Producing Specifications

Goal: The Technical report page (/TR) should represent the Web

• Improving our editorial workflow
• Managing our repository of specifications

Setting your editing space

1. W3C on GitHub: https://w3c.github.io/
2. Use the tooling: pull requests preview and diff, github digest,
3. W3C RF Policy tool: Repository Manager (see training)
4. Automatic publishing: support for CR coming in 2018
5. Use proper GitHub labels

Editing the specification

Use a pull request workflow for editorial and substantive changes

• Facilitate discussions and reviews
• Merge when support
• Easier to switch to auto publish if your ed draft has builtin consensus
• Helps with testing (see later)
• See Workflow for editors and other contributors (work in progress)

Managing our repository of specifications

• over 6000 drafts on w3.org, including ~300 Recommendations
• Automatic outdating previous versions
• Managing versioning and links

Managing versioning and links

• /TR/foobar-<N>: : latest draft of foobar <N>
• /TR/foobar/latest: the highest level being a CR, a PR, or a REC
• /TR/foobar/upcoming: the highest level of a draft
• /TR/foobar: proxy to [ latest | upcoming ]
• /TR/foobar/ed: redirect to the editor draft
• /TR/foobar/all: cover page for all foobar versions
• See Latest versions proposal for leveled specifications

Note: this is work in progress. Report errors to webreq@w3.org

Future of /TR

• Incorporate the new links into our pubrules: what would you want to see on the spec? (see proposal)
• Revamp the main /TR page: allowing different views, tag filtering, etc.
• Next specification redesign in 2018

Reminder: Get Your Wide Review

• Start early to get reviews (shortly before CR is often too late to fix things)
• Publish often to get more eyes (don't let /TR decay)
• Put feedback questions in your specifications
• Leave enough time for the reviewers
• Use the "wide review" in your WD SOTD. Our tools will pick that up.
• Get your horizontal reviews (TAG, security, a11, i18n, ...)

Part 2: Achieving Interoperability

• Web stakeholders: Implementors, Specifications Writers, Documentation (eg MDN), Developers
• web-platform-tests, the testing open source project, is intended as a new stakeholder of the Web

web-platform-tests.org

• Open-source effort to build a cross-browser testsuite for the majority of the web platform
• Use GitHub for submissions, reviews and infrastructure deployment
• One repository for tests and tools
• WPT has been adopted by W3C, WHATWG, and ALL major browsers

Why use web-platform-tests?

• WPT folks know how to test the Web
• WPT folks want the Web to work, no exceptions
• A growing number of browser vendors are running the tests
• WPT folks have a lot of test infrastructure ready to use
• Your lifespan is too short to reinvent it

Current tests

• ~180 specifications are being tested
• Generate around ~1.3M results per product run
  • encoding: ~900k
  • editing: ~90k
  • html: ~89k
  • dom: ~59k
  • WebCrypto: ~38k

W3C and Implementation Experience

(aka Candidate Recommendation phase)

• Is each feature implemented?
• Are there independent interoperable implementations?
• Is there experience at all levels (authoring, consuming, publishing…)?

Testing at W3C

• Don't wait for CR to worry about testing, otherwise your backlog will be too high
• Consider adopting a healthy testing policy, such as:
  all changes made to specifications should have tests
• Using pull requests to edit your specs? link your edits with your tests
• web-platform-tests.org is our platform for testing so use it

Following-up

• /TR breakout session (by PLH)
• Testing session (by foolip)

Thank you,
and let's keep making the Web better!