canmove, Confirmed users
901
edits
ExposureGuidelines: Difference between revisions
no edit summary
No edit summary |
|||
| Line 11: | Line 11: | ||
# Shipping | # Shipping | ||
# Policy enforcement | # Policy enforcement | ||
=Standardization= | =Standardization= | ||
| Line 32: | Line 26: | ||
# APIs which only Mozilla is interested in at that time. In cases such as this (which will likely be rare), Mozilla will solicit feedback from as many relevant parties as possible, begin the standardization process with a relevant standards body, and create a test suite as part of the standards process. An example of this is the Push Notifications API. | # APIs which only Mozilla is interested in at that time. In cases such as this (which will likely be rare), Mozilla will solicit feedback from as many relevant parties as possible, begin the standardization process with a relevant standards body, and create a test suite as part of the standards process. An example of this is the Push Notifications API. | ||
# APIs which will be hidden behind preferences. APIs like this can also skip the required API review (see below). | # APIs which will be hidden behind preferences. APIs like this can also skip the required API review (see below). | ||
=Declaring Intent= | |||
Developers of new APIs intended to be exposed to the web at large via Mozilla products must send an email to [https://lists.mozilla.org/listinfo/dev-platform dev-platform] and [https://lists.mozilla.org/listinfo/dev-webapi dev-webapi] declaring their intent to implement this API. This email must have a subject line that begins with "Intent to implement:" and whose body describes the feature and links to relevant documentation. It must also demonstrate that an API is standardized as [[Special:MyPage/APIExposurePolicy#Standardization|defined below]]. Implementors must also use this email to request API review from the Mozilla [[Special:MyPage/APIExposurePolicy#API_review|API review]] team. These emails must be sent ''early on'' in the process of any new API's development, especially if this work is being done as part of a standards body (ie. before [http://www.w3.org/2005/10/Process-20051014/tr#q74 W3C CR status]). This will expose the API to a(n even) larger audience which can help improve its quality and avoid APIs which are designed by domain experts but aren't "webby" or friendly to JS developers. The API review team can help with the latter concern. | |||
=API review= | |||
The Mozilla API review team will consist of Mozillians who have experience designing JS APIs and will have at least one representative from the JS team at all times. This team will respond to review requests for all proposed APIs. Disputes between the API review team and the API developers will be decided by the module owner for the API's area. | |||
=Implementation= | =Implementation= | ||