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.