Confirmed users
112
edits
ExposureGuidelines: Difference between revisions
→Email templates: deduplicate "intent to ship" and "intent to implement"; add "intent to implement and ship"
(→Intent to implement: add secure contexts to intent to implement template) |
(→Email templates: deduplicate "intent to ship" and "intent to implement"; add "intent to implement and ship") |
||
| Line 86: | Line 86: | ||
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). | 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== | ==Intent to ship== | ||
| Line 96: | Line 96: | ||
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>. | 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>. | ||
''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 /> | ''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 /> | ||
This 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== | ||
'''To''': <tt>dev-platform@lists.mozilla.org</tt><br /> | |||
'''Subject''': Intent to implement and ship: <your feature goes here> | |||
It's acceptable to combine the "intent to implement" and "intent to ship" emails as long as all the relevant requirements are met. | |||
| Line 121: | Line 114: | ||
<The body of the email should contain rationale, telemetry analysis, links to related discussions if any, and developer console suggestions.> | <The body of the email should contain rationale, telemetry analysis, links to related discussions if any, and developer console suggestions.> | ||
= See Also = | = See Also = | ||