Changes

* ''How stable is the spec'': Note that even if it's unstable that shouldn't stop us implementing; that mostly affects shipping. So as long as we're pretty sure that the basic set of functionality is stable, even if the actual names of the values are not, implementing makes sense.

* ''Security & Privacy Concerns'': consider providing a link to answers in [https://mikewest.github.io/spec-questionnaire/security-privacy/ this security/privacy questionnaire] for a spec feature, if the spec doesn't already answer it. In particular, consider if the spec exposes new information about a user's computer or behavior that can contribute to fingerprinting.

* ''Web designer / developer use-cases'' AKA ''Why a developer would use Feature X?'': Provide a URL to at least briefly documented use-cases for web designers and developers that illustrate why and when they would use this feature. E.g. a link to an https://webwewant.fyi/wants/ entry with that information.

* ''Example'': Provide a brief code sample on how to use the API. Even with a formal specification, not everyone will know about the feature just from the name of the spec. An example will make it easier to understand how this feature can be used. This can either be an inline code sample, or a direct link to an example on the web.

==Intent to ship==