MozillaWiki

ExposureGuidelines: Difference between revisions

Page Discussion

ExposureGuidelines (view source)

Revision as of 13:04, 3 November 2020

468 bytes removed ,  3 November 2020
Add clearer evaluation guidelines around feature additions/changes/removals
(Add clearer evaluation guidelines around feature additions/changes/removals)
Line 1: Line 1:
=Adding features=
'''Always ask: ''Is this good for the web?'''''


One way Mozilla aims to advance the state of the web platform is with new features. Always ask: ''Is this good for the web?''
=Adding or changing features=


If you aim to expose a new feature to the web or change an existing feature, please follow these steps:
If you aim to expose a new feature to the web or change an existing feature, please follow these steps:


# [[#Evaluating new features|Evaluate the new feature]] or [[#Evaluating changes|change to an existing features]].
# Email [https://lists.mozilla.org/listinfo/dev-platform dev-platform] declaring your [[#Intent to prototype|intent to prototype]]. (It is okay to skip this step for small changes.)
# Email [https://lists.mozilla.org/listinfo/dev-platform dev-platform] declaring your [[#Intent to prototype|intent to prototype]]. (It is okay to skip this step for small changes.)
## 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, [https://github.com/w3c/web-platform-tests web-platform-tests] will be written, etc.
# 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].
## Ensure the feature has [https://github.com/w3c/web-platform-tests web-platform-tests] coverage.
## Land potentially disruptive features behind a preference which is off by default.
# Email [https://lists.mozilla.org/listinfo/dev-platform dev-platform] declaring your [[#Intent to ship|intent to ship]] on [[Release_Management/Release_Process|Firefox Release]].
# Email [https://lists.mozilla.org/listinfo/dev-platform dev-platform] declaring your [[#Intent to ship|intent to ship]] on [[Release_Management/Release_Process|Firefox Release]].
# If there's no negative feedback, ship.
# If there's no negative feedback, ship it!
 
==Evaluating new features==
 
There’s a lot of nuance that goes into adding a feature to the web. These questions will help to evaluate if it is worth doing and what it takes to do it.
 
===Why is the feature important?===
 
Given that we only have a finite amount of time, why are we pursuing this? For example:
* It’s of strategic importance to Mozilla.
* This will make us the second/third browser to ship this enabling more web developers to use it. I.e., this helps with web compatibility and moves the web forward by having another independent implementation.
 
===Is the feature covered by a specification?===
 
New features in Gecko should meet these requirements:
* There should be a specification that describes the feature that is adopted by a standards group that intends to produce a standard out of it.
* That group should consider the specification to be sufficiently stable.
Mozilla sets a relatively high bar for any changes we make to the web to ensure there is broad support. I.e., non-WG IETF drafts (shortname does not start with draft-ietf) or drafts from W3C CGs do not count.
 
If your feature needs an exception to this rule, please reach out to [[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership]].
 
===Does Mozilla have a position on the feature?===
 
If you are unsure whether the feature has broader support within Mozilla, [https://github.com/mozilla/standards-positions standards-positions] is a useful way of determining that.
 
==Evaluating changes==
 
When making changes to existing features or even removing existing features many of the considerations stated for [[#Evaluating new features|evaluating new features]] apply, but one thing 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 go.


==Intent to prototype==
==Intent to prototype==
Line 61: Line 85:
=Removing features=
=Removing features=


Occasionally there is a need to remove features. These could be features that are proprietary to Mozilla, were standardized but never got adopted by all browsers, or features that are so bad that all browsers want to get rid of them together.
If you aim to remove a feature from the web, please follow these steps:
 
In order to make this possible while impacting users as little as possible the following steps are to be taken:


* Gather telemetry on the feature.
# [[#Evaluating changes|Evaluate the removal]].
* Consult dev-platform with an [[#Intent to unship|intent to unship]] that includes the telemetry data.
# 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.
# 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.
* Remove the feature when the telemetry data and dev-platform agreement indicate it can be.
# Unship the feature when all is in order.


==Intent to unship==
==Intent to unship==
Line 90: Line 112:


=FAQ=
=FAQ=
==When is a feature ready to ship?==
Features which Mozilla makes available by default to the web on the release channel should be "ready".  This can mean that they are de jure standards (e.g., a W3C Recommendation) or de facto standards. Indications that a feature is ready for shipping to the web include:
# other browser engines ship compatible implementations in their releases or behind a preference with clear signals it will graduate to being on by default
# other browser engines state their ''intention'' to ship a compatible implementation
# a large number of web developers indicate their satisfaction with the feature design
# there exists a specification that is no longer at risk of significant changes, is on track to become a standard with a relevant standards body, and is acceptable to a number of applicable parties and other browser engines


==How do we know what web developers want?==
==How do we know what web developers want?==
Line 110: Line 123:
* Watch for positive signals on the specification's discussion forum (likely a GitHub repository)
* Watch for positive signals on the specification's discussion forum (likely 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]
* Watch for "intent to *" 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?==
==How do we let other browser engines know what we think?==
Line 122: Line 133:


In the past, Mozilla has shipped experimental features with a "moz" prefix to indicate their lack of standardization (e.g., <code>mozRequestAnimationFrame()</code>). Unfortunately, this approach turned out to be harmful to the web as experimental features ended up being used in some websites before they were ready. In many cases, this meant that we were unable to innovate on certain features because to change them would break content on the web. Browsers have in some cases also been [https://compat.spec.whatwg.org/ forced to implement each other's prefixed features]. Therefore, to allow us to continue innovating without negatively affecting content on the web, '''Mozilla will no longer ship new "moz"-prefixed features''' (see [https://groups.google.com/forum/#!topic/mozilla.dev.platform/34JfwyEh5e4 Henri Sivonen's proposal]).
In the past, Mozilla has shipped experimental features with a "moz" prefix to indicate their lack of standardization (e.g., <code>mozRequestAnimationFrame()</code>). Unfortunately, this approach turned out to be harmful to the web as experimental features ended up being used in some websites before they were ready. In many cases, this meant that we were unable to innovate on certain features because to change them would break content on the web. Browsers have in some cases also been [https://compat.spec.whatwg.org/ forced to implement each other's prefixed features]. Therefore, to allow us to continue innovating without negatively affecting content on the web, '''Mozilla will no longer ship new "moz"-prefixed features''' (see [https://groups.google.com/forum/#!topic/mozilla.dev.platform/34JfwyEh5e4 Henri Sivonen's proposal]).
We will instead prototype features behind preferences which can be toggled through <code>about:config</code>. Once we feel there is an acceptable level of consensus in the web community about the stability of an feature and we feel it is ready, we will make it generally available to the web platform (more details below on this process). We feel this strikes the right balance between allowing developers to experiment with new features, while at the same time protecting the web from being exposed to new functionality prematurely.


==Who decides?==
==Who decides?==


If the dev-platform thread results in a conflict, the respective [[Modules|module owner]] is responsible for resolving that conflict and making a decision on how to proceed.
If the dev-platform thread results in a conflict, the respective [[Modules|module owner]] is responsible for resolving that conflict and making a decision on how to proceed.
Annevk
Confirmed users
112

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1231989"