User:Shaver/AMO Extension Policy: Difference between revisions

binary components and reviews
(binary components and reviews)
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
'''Your comments are welcome''', but please make them on [[User_talk:Shaver/AMO_Extension_Policy|the discussion page]] rather than editing them inline here.  Thank you!
__TOC__
(See also: {{bug|245198}})
(See also: {{bug|245198}})


Line 10: Line 14:


All listings, content, positioning, and availability of add-ons and related material on AMO is at the discretion of Mozilla, and Mozilla reserves the right to remove or modify such material as it deems necessary and appropriate to serve the interests of the project and its users.
All listings, content, positioning, and availability of add-ons and related material on AMO is at the discretion of Mozilla, and Mozilla reserves the right to remove or modify such material as it deems necessary and appropriate to serve the interests of the project and its users.
= Code review and binary components =
The administrators and reviewers on AMO may reject an add-on submission if it contains code that is obfuscated in such a way as to impair review (whether intentionally or not).  Compiled code is obviously difficult to review, and as such add-ons may be rejected or kept in "admin purgatory" until Mozilla is satisfied that it does not present undue risk to users.  Add-on authors who feel that they have a compelling case for approval of their binary-including add-on should make that case in a bug or mail message (address TBD), and should expect that their request will be looked at with a very critical eye.  Any add-on with a binary component should be signed by the author, as well.


= Descriptions and add-on naming =
= Descriptions and add-on naming =
Line 27: Line 35:
Add-on names should not:
Add-on names should not:


* inappropriately use trademarks, including [http://www.mozilla.org/foundation/trademarks/ Mozilla trademarks] held by people other than the author
* inappropriately use trademarks, including [http://www.mozilla.org/foundation/trademarks/ Mozilla trademarks], held by people other than the author
* be confusingly similar to other add-ons or software
* be confusingly similar to other add-ons or software
* be chosen to "game" or otherwise manipulate sort/display order, search, or rating systems [[#Rating_systems|rating systems]]
* be chosen to "cheat" or otherwise manipulate sort/display order, search, or [[#Rating_systems|rating systems]]
 
* OK: "Wibblotron for Firefox"
* Not OK: "Firefox Wibblotron"
* OK: "Network Explorer"
* Not OK: "Opera 9"
 
= Categorization =
 
Categories are used to help users navigate the collection of add-ons more narrowly, such that they are better able to find an add-on that will suit their current need.  Add-ons should be categorized according to the major capability provided by the add-on.  In the vast majority of cases this means that an add-on should be in only 1 or 2 categories.


OK: "Wibblotron for Firefox"
Add-ons which represent a bundle of largely-unrelated functionality will need to decide which of their features is most worthy of labelling via a category.  An extension that provides a way to encrypt bookmarks so that they could be shared on a specific forum would be primarily a "site-specific" add-on, and should be categorized appropriately.
Not OK: "Firefox Wibblotron"
 
OK: "Network Explorer"
(We could add a "grab-bag" category for extensions like the Conduit-based toolbars which provide everything ranging from a "pop-up blocker" to RSS feeds, with many stops in between.)
Not OK: "Opera 9"


= Collection of user data =
= Collection of user data =
Line 40: Line 56:
* description of the add-on must clearly indicate that such collection occurs
* description of the add-on must clearly indicate that such collection occurs
* description of the add-on must include a link to the privacy policy for the organization/site to which the data is reported
* description of the add-on must include a link to the privacy policy for the organization/site to which the data is reported
* the privacy policy must clearly indicate what data is collected, by whom, and what the data is used for, as well as who the user should contact for
* the collection of personal data should be restricted to that data which is necessary for the proper operation of the add-on; additional instrumentation or data collection for usability analysis or other such ends should be on an opt-in basis
The privacy policy document should be clear and factual, and focus on what _is_ done with the data; it is not a marketing vehicle, and should not spend significant space describing what is _not_ done with the data.


Relevant AMO bugs:
Relevant AMO bugs:
Line 45: Line 65:
* {{bug|335707}} Permit developers to provide a link to a privacy policy for their extensions
* {{bug|335707}} Permit developers to provide a link to a privacy policy for their extensions
* {{bug|335708}} Display privacy policy link for extensions in listings
* {{bug|335708}} Display privacy policy link for extensions in listings
== More detail: EffectiveBrand toolbars ==
EffectiveBrand toolbars are only permitted if they meet both of the preceding requirements, *and* are based on version 1.0.1.13 (or later) of the EffectiveBrand code. Toolbars based on older versions of the EB code should be denied, with a comment indicating that the developer needs to update to use at least 1.0.1.13.  The version number of the extension (as from install.rdf) will match the toolbar code's version in virtually all cases, but if you want to check more closely:
* The drop-down menu next to the toolbar logo has an "About" entry which will show the version number.
* You can unzip the inner chrome/*.jar and look in about.xul and/or ebToolbarJS.js for the version strings.


= Rating systems =
= Rating systems =
Confirmed users
455

edits