User:Shaver/AMO Extension Policy: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
(binary components and reviews)
 
(18 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}})
= Guiding Principle =
= Guiding Principle =


Users should get what they expect from extensions.
Users should get what they expect from add-ons.


Descriptions and names should set expectations (and not mislead), manipulation of personal data must be subject to informed user consent, and extensions should be updated promptly to resolve significant bugs or version compatibility.  Ratings and reviews and categorization should fairly and reasonably describe the behaviour that the user will see if they install the extension.
Descriptions and names should set expectations (and not mislead), manipulation of personal data must be subject to informed user consent, and add-ons should be updated promptly to resolve significant bugs or version compatibility.  Ratings and reviews and categorization should fairly and reasonably describe the behaviour that the user will see if they install the add-ons.


= Descriptions and extension naming =
== Veto rule ==
 
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 need to clearly inform the (potential) user of
Descriptions need to clearly inform the (potential) user of


* the purpose of the extension
* the purpose of the add-on
* what, if any, other software or subscriptions/accounts are necessary to use the extension
* what, if any, other software or subscriptions/accounts are necessary to use the extension
* how to activate the extension's functionality, if not obvious.
* how to activate the add-on's functionality, if not obvious.
 
Descriptions, names, and related text must be in the interface language of the site (currently English for AMO, other languages as those come on line).


Relevant AMO bugs:
Relevant AMO bugs:
Line 17: Line 33:
* {{bug|338271}} Need support for optional shorter summary, with length cap
* {{bug|338271}} Need support for optional shorter summary, with length cap


Extension names should not:
Add-on names should not:


* inappropriately use 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 extensions or software
* be confusingly similar to other add-ons or software
* be chosen to "game" or otherwise manipulate sort/display order, search, rating systems, or international currency markets
* be chosen to "cheat" or otherwise manipulate sort/display order, search, or [[#Rating_systems|rating systems]]


OK: "Wibblotron for Firefox"
* OK: "Wibblotron for Firefox"
Not OK: "Firefox Wibblotron"
* Not OK: "Firefox Wibblotron"
OK: "Network Explorer"
* OK: "Network Explorer"
Not OK: "Opera 9"
* 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.
 
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.
 
(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.)


= Collection of user data =
= Collection of user data =


* description of the extension must clearly indicate that such collection occurs
* description of the add-on must clearly indicate that such collection occurs
* description of the extension 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 38: Line 66:
* {{bug|335708}} Display privacy policy link for extensions in listings
* {{bug|335708}} Display privacy policy link for extensions in listings


== More detail: EffectiveBrand toolbars ==
= Rating systems =
 
AMO employs various rating and weighting systems to help users find the add-ons most likely to please them, and to profile and reward the best add-ons.  Attempts, successful or otherwise, to "game" the rating systems in order to artificially increase or decrease the ranking or visibility of an add-on are not permitted, and may result in measures such as removal of an add-on, resetting of statistics for an add-on, or various blocks and bans.
 
We encourage people to give positive and negative ratings wherever they feel it's appropriate, and add-on creators are free to encourage fans of their add-ons to rate it highly.  Encouraging indiscriminate positive ratings ("everyone go make a bunch of AMO account and rate our extension 5/5!") will be cause for scrutiny, and virtually all cases of encouraging ''negative'' reviews of other add-ons will be considered to be abuse.
 
Abuse of AMO's listings, comment system, or other facilities to manipulate ''other'' rating systems is also prohibited.
 
= Creator responsiveness =


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:
We expect that add-ons on AMO will be maintained to ensure compatibility with new stable/security releases (e.g. 1.5.0.5, for add-ons that are released for use with Firefox 1.5), and that add-on creators will respond appropriately to feedback regarding major issues (especially security and stability issues).


* The drop-down menu next to the toolbar logo has an "About" entry which will show the version number.
Failure to respond to messages from AMO staff, or to act in a timely manner on requests for fixes to significant issues (especially those related to security or application stability) may result in an add-on being marked inactive or removed from certain listings, having warning text added to the description, or having the add-on removed from the site altogether.
* You can unzip the inner chrome/*.jar and look in about.xul and/or ebToolbarJS.js for the version strings.

Latest revision as of 16:44, 28 November 2006

Your comments are welcome, but please make them on the discussion page rather than editing them inline here. Thank you!

(See also: bug 245198)

Guiding Principle

Users should get what they expect from add-ons.

Descriptions and names should set expectations (and not mislead), manipulation of personal data must be subject to informed user consent, and add-ons should be updated promptly to resolve significant bugs or version compatibility. Ratings and reviews and categorization should fairly and reasonably describe the behaviour that the user will see if they install the add-ons.

Veto rule

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 need to clearly inform the (potential) user of

  • the purpose of the add-on
  • what, if any, other software or subscriptions/accounts are necessary to use the extension
  • how to activate the add-on's functionality, if not obvious.

Descriptions, names, and related text must be in the interface language of the site (currently English for AMO, other languages as those come on line).

Relevant AMO bugs:

  • bug 338271 Need support for optional shorter summary, with length cap

Add-on names should not:

  • inappropriately use trademarks, including Mozilla trademarks, held by people other than the author
  • be confusingly similar to other add-ons or software
  • be chosen to "cheat" or otherwise manipulate sort/display order, search, or 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.

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.

(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.)

Collection of user data

  • 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
  • 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:

  • 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

Rating systems

AMO employs various rating and weighting systems to help users find the add-ons most likely to please them, and to profile and reward the best add-ons. Attempts, successful or otherwise, to "game" the rating systems in order to artificially increase or decrease the ranking or visibility of an add-on are not permitted, and may result in measures such as removal of an add-on, resetting of statistics for an add-on, or various blocks and bans.

We encourage people to give positive and negative ratings wherever they feel it's appropriate, and add-on creators are free to encourage fans of their add-ons to rate it highly. Encouraging indiscriminate positive ratings ("everyone go make a bunch of AMO account and rate our extension 5/5!") will be cause for scrutiny, and virtually all cases of encouraging negative reviews of other add-ons will be considered to be abuse.

Abuse of AMO's listings, comment system, or other facilities to manipulate other rating systems is also prohibited.

Creator responsiveness

We expect that add-ons on AMO will be maintained to ensure compatibility with new stable/security releases (e.g. 1.5.0.5, for add-ons that are released for use with Firefox 1.5), and that add-on creators will respond appropriately to feedback regarding major issues (especially security and stability issues).

Failure to respond to messages from AMO staff, or to act in a timely manner on requests for fixes to significant issues (especially those related to security or application stability) may result in an add-on being marked inactive or removed from certain listings, having warning text added to the description, or having the add-on removed from the site altogether.