If you aim to expose a new feature to the web or change an existing feature, please follow the steps below. Note that trivial changes might not need to worry about this.
# Email [https://lists.mozilla.org/listinfo/dev-platform dev-platform] declaring your [[#Intent to implementprototype|intent to implementprototype]] or [[#Intent to ship|intent to ship]]. If you are implementing a feature that is working its way through a standards body process such as the W3C's, it's best to email as soon as possible (i.e., before [http://www.w3.org/2005/10/Process-20051014/tr#q74 W3C CR status] if possible).
# Implement as normal. Code review rounds will take place, etc. Module owners or their designated peers will provide a super-review for all interface changes.
# [https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ Restrict the feature to secure contexts].
# Land potentially disruptive features behind a preference which is off by default.
==Intent to implementprototype==
'''To''': <tt>dev-platform@lists.mozilla.org</tt><br />
'''Subject''': Intent to implementprototype: <your feature goes here>
''Summary'': [https://en.wikipedia.org/wiki/Elevator_pitch elevator pitch] for the new functionality including benefits to web developers.<br />
''Preference'': if applicable, how can interested parties test this before it ships pref'd on by default?<br />
''DevTools bug'': link to a [https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Developer%20Tools Firefox :: Developer Tools bug] coordinating work with the DevTools team to build tools for this feature.<br />
''Other browsers'': address with shipped (since version X, behind what flags if any), intent to implement emailed (mailing list URL), or considering (citation).<br />
''web-platform-tests'': Please link to the test suite. If any part of the feature is not tested by web-platform-tests, please include links to one or more of:
* A web-platform-tests issue explaining why a certain thing cannot be tested ([https://github.com/w3c/web-platform-tests/issues/3867 example]).
===Suggested additions===
The above is the minimum required that should be in an "Intent to implementprototype" email. If you've covered those, you're good, and brevity is a virtue.
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).
''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 implementprototype" thread: <https://groups.google.com/forum/#!forum/mozilla.dev.platform>. '''If anything changed since that thread please include that information in this email'''.
It's acceptable to merge the "intent to implementprototype" into the "intent to ship" email as long as all the relevant requirements are met.
==How do we know what other browser engines think?==
* some Some of them participate in dev-platform discussions* watch Watch for positive signals on the specification's discussion forum (likely a GitHub repository)* watch Watch for "intent to implement*" emails on mailing lists such as [https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev blink-dev]* Note: lack of feedback will not delay our implementation as it may simply indicate lack of interest at that time from another browser engine.
==How do we let other browser engines know what we think?==
* By documenting our position on [standards-positions https://github.com/mozilla/standards-positions].
* Participating in public discussions of new features.
* Comment on "intent to implement*" threads on [https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev blink-dev].
==What about prefixes?==