Confirm
23
edits
Changes
Revise with more details on standardization
=Adding or changing features=
This process applies to all new features that change how the web platform operates.
If you aim to expose a new feature to the web or change an existing feature, please follow these steps:
# [[#Evaluating new New features|Evaluate the new feature]] or [[#Evaluating changesChanging or evolving features|change to an existing features]].
# Email [https://groups.google.com/a/mozilla.org/g/dev-platform dev-platform] declaring your [[#Intent to prototype|intent to prototype]]. (It is okay to skip this step for small changes.)
# Implement as normal. Code review rounds will take place, [https://github.com/w3c/web-platform-tests web-platform-tests] will be written, etc.
# If there's no negative feedback, ship it!
==Evaluating new New features==
There’s a lot of nuance that goes into adding a feature to the web. These questions will help Mozilla sets a high bar for any changes we make to evaluate if it is worth doing and what it takes to do itthe web.
* It’s of strategic importance to Mozilla.
* It contributes to [https://www.mozilla.org/en-US/about/manifesto/ Mozilla’s mission].* This will make us the second/third browser to ship this , enabling more web developers to use it. I.e.That is, this helps with web compatibility and moves the web forward by having another independent implementation. ==Ensure that the feature is standardized== Mozilla is committed to standardization as the basis for evolving the Web. We want to ensure that features are good for our users and have broad support from other browsers, web developers, and the broader community. The standards process is how we ensure that features meet these expectations. Our goal is that all new web-facing features are based on a specification that is the product of a recognized standards body. ===Standardization requirements for prototypes=== If a specification for a feature is not the product of a standards body, your intent to prototype needs to identify what steps have been taken to ensure that it will be. You should identify which standards body you believe should take the work on. Include a link to a record from that standards body that tracks the feature becoming an official product. What you minimally need to show might differ according to the processes of the standards body: * '''W3C''' - an issue raised on a working group charter (not a community group)* '''WHATWG''' - an issue raised on the appropriate standard(s)* '''IETF''' - an explicit request for adoption by a working group* '''TC39''' - a link to a proposal at stage 1 or higher* For other bodies, a request for consideration according to the procedures of the body Being able to prototype new features allows us to learn about them, but experimentation serves to inform our choices in standards bodies. Features that have not been discussed within the processes of a standards body will require extra scrutiny to ensure that it is safe to prototype. This applies especially to W3C work that is outside of community groups and individual submissions to the IETF. ===Standardization requirements for shipping features=== An intent to ship must include an update on the standardization status of the feature. We expect that shipping features will be further advanced in the standards process when they ship. Your intent to ship should include information that shows not only that the standards body has adopted the work, but also that there is consensus that the feature is ready to be shipped. What evidence is necessary will vary, but generally this will be: * '''W3C''' - the specification is at the Candidate Recommendation [https://www.w3.org/2021/Process-20211102/#maturity-levels maturity level] or more advanced; shipping from a Working Draft or a less advanced specification requires evidence of agreement within the working group that shipping is acceptable* '''WHATWG''' - the changes have been merged into a standard; an open pull request requires additional evidence of agreement among implementers that shipping is acceptable* '''IETF''' - a working group draft that has been passed to the IESG for publication by the working group; a draft working group in an earlier state should show evidence that shipping is acceptable to the working group* '''TC39''' - the proposal is at stage 3 or higher* The product of other bodies will be assessed individually In all of these cases, try to show that there are no significant unresolved issues with a specification and that there are no objections to shipping it. Simply showing that there is support for a feature is less useful. Shipping features that don’t meet these requirements is still possible, including features that don't show broad agreement that shipping is acceptable. If your feature needs an exception to this rule, please reach out to [[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership]]. Any intent regarding a non-standard feature might need to include additional safeguards such as experimentation and data collection plans, risk assessments, and rollback strategies.
===Is Ensure that Mozilla has a position on the feature covered by a specification?===
==Evaluating changes=Email templates for new or changed features=
When making changes announcing your intent to existing features prototype or even removing existing features many of the considerations stated for [[#Evaluating new features|evaluating new features]] applyship a feature, but one thing using these templates ensures that is quite different is that telemetry might be important here as in general Mozilla is pretty averse to shipping breaking changes. Coordination with the relevant standard and other browsers is usually the way to goyou don’t miss anything critical.
==Intent to prototype==
''Summary'': [https://en.wikipedia.org/wiki/Elevator_pitch elevator pitch] for the new functionality including benefits to users and web developers.<br>
''Bug'': link to Bugzilla (tracking) bug.<br />
''StandardSpecification'': link to standard or the specification (see [[#Standardization requirements for prototypes|details above]]<br />''Standards Body'': identify the standards body responsible for standardizing this feature if that is not obvious from the specification; if the specification is not already adopted by a standards body, link to public discussions with other browser vendors.the issue or a discussion about adoption of the work (if no discussion exists, please start that process before filing this intent)<br />
''Platform coverage'': where will this be available? Android, Desktop, only exposed to privileged apps (certified app-only functionality does not require an email), etc.<br />
''Preference'': if applicable, how can interested parties test this before it ships pref'd on by default?<br />
''Bug to turn on by default'': link to main relevant bug (https://bugzilla.mozilla.org/show_bug.cgi?id=) Please set the ''dev-doc-needed'' keyword.
Standard: link to the standard; if the work is not yet part of a standard, also provide evidence that the responsible standards body has agreement that shipping the feature has broad support (see [[#Standardization requirements for shipping features|details above]])
This feature was previously discussed in this "Intent to prototype" 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 prototype" into the "intent to ship" email as long as all the relevant requirements are met.
=Removing features=
If you aim to remove a feature from the web, please follow these steps:
# [[#Evaluating changesChanging or evolving features|Evaluate the removal]].
# Consult dev-platform with an [[#Intent to unship|intent to unship]] that includes any relevant data.
# Indicate in the developer console whenever the feature is used that it's deprecated and might be removed. It's best to avoid doing this until there's agreement that the feature can be removed (which requires telemetry) as otherwise developers are needlessly spammed in the console.
<Include rationale, telemetry analysis, links to related discussions if any, and developer console suggestions.>
</blockquote>
= See Also =
* [https://www.chromium.org/blink Chrome/Blink change process]
** [https://www.chromium.org/blink/launching-features Chrome/Blink process for Launching Features] in particular
** [https://bit.ly/blink-signals Signals from other implementations]
=FAQ=
* Most of the time this should fall out of the standardization process (e.g., discussion in a GitHub repository)
* Watch for "intent to *" emails on mailing lists such as [https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev blink-dev]
* By asking! * WebKit (Apple) can be asked on the [mailto:webkit-dev@lists.webkit.org webkit-dev] list.
==How do we let other browser engines know what we think?==
* By documenting our position on [https://github.com/mozilla/standards-positions standards-positions].
* Participating in public discussions of new features.
* Comment on "intent Intent to *" threads on [https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev blink-dev]. (Ideally this is not necessary, but it's a good last resort option.)
==What about prefixes?==
