Changes

Jump to: navigation, search

ExposureGuidelines

813 bytes removed, 09:17, 17 January 2018
Email templates: deduplicate "intent to ship" and "intent to implement"; add "intent to implement and ship"
If you're looking for extra credit, or to preempt common questions, consider adding any or all of the following (all based on existing dev-platform examples, and questions asked on dev-platform in response to intent to ship emails).
* '''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.* '''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==
As of <target date> I intend to turn <feature> on by default [<on these platforms>]. It has been developed behind the <pref> preference. Other UAs shipping this or intending to ship it are <details>.
 
This feature was previously discussed in this "intent to implement" thread: <https://groups.google.com/forum/#!forum/mozilla.dev.platform>.
''Bug to turn on by default'': link to main relevant bug (https://bugzilla.mozilla.org/show_bug.cgi?id=) ['''note''': this bug should ideally have the ''dev-doc-needed'' keyword set]<br />
''Link to standard'': note here what has transpired with the specification since your original intent to implement email was sent
TestingThis feature was previously discussed in this "intent to implement" thread: <https://groups.google.com/forum/#!forum/mozilla.dev.platform>. '''If anything changed since that thread please include that information in this email'''.
==Intent to implement and ship=='''Is this feature fully tested by webTo''': <tt>dev-platform-tests?@lists.mozilla.org</tt><br />'''Subject''': Intent to implement and ship: <your feature goes here>
Please link to the test suite. If any part of the feature is not tested by web-platform-tests, please include links to issues, e.g.:* A web-platform-tests issue with the "infra" label explaining why a certain thing cannot be tested. ([https://github.com/w3c/web-platform-tests/issues/3867 example])* A spec issue for some change that would make it possible to test. ([https://github.com/whatwg/fullscreen/issues/70 example]) An Intent to Ship requires either a web platform test suite or such issues to be filed explaining why such a test suite is currently impossible or in the progress of being upstreamed. ''Example'It': Similar s acceptable to combine the "intent to implement", provide a brief example on how the new feature can be used by a developer. This will help adoption and the reader does not have "intent to skim the specification or bug patches to find a working example. This can either be a code sample, or a direct link to an example (e.g. bug comment or anchor within ship" emails as long as all the specification)relevant requirements are met.
<The body of the email should contain rationale, telemetry analysis, links to related discussions if any, and developer console suggestions.>
 
= See Also =
Confirm
112
edits

Navigation menu