Mitigate quality impact of single implementations on W3C standardization process

As highlighted in #1, one of the expected benefits of the standardization process that recommends getting multiple independent implementations is to improve the robustness of the specification by getting different people/teams to turn the words of the spec into running code.

When a big chunk of that implementation work happens in only one shared implementation, it may be useful to document good practices (and possibly more formal policies) to ensure these benefits aren't completely lost.

Some of the early ideas that have been evoked:

first, ensuring that the shared code is indeed open source is probably a critical piece of ensuring proper review and accountability; there may be specific licensing considerations to take into account in terms of checking the open-source nature of the said code
looking at the governance of the OSS project itself to see how much its own review processes might help alleviate some of these concerns (both in terms of spec conformance and in terms of multi-stakeholderism)
another form of "turning spec-into-code" effort happens when building the test suite - so determining how the accompanying (spec and/or software) test suite is being built, how much of the spec it covers might provide additional guarantees
yet another form of "turning spec-into-code" effort might happen in the development of polyfills - they may not be full implementation of the spec, but might provide additional perspectives on the implementability of the spec

w3c / oss-relations

Mitigate quality impact of single implementations on W3C standardization process #3