Approval Queue

Metrics

I think we should take a look at making the review queue just one of many ways an add-on is "reviewed". Think of the other ways we could rate things and how much weight each of these sources should get:

user feedback, weighted based on the user's feedback rating (good reviewers' opinions score higher)
reviewer feedback, from the queue itself
mozilla QA approval (recommended list)
user ratings (thumbs up/thumbs down)
favorites list membership (how many times a user lists it as a favorite)
update check frequency (how many users actually use it)

Morgamic

[02:13] <morgamic> what could we do to make the good add-ons float to the top based on popular opinion as well as some minor reviewing by our reviewers?
[02:13] <fligtar> If we have a queue, I would prefer it list the extension name, and very very basic info like supported apps/oses and then you click to see an approval page where we can dump all the info instead of hiding the form and description and such
[02:15] <fligtar> we could add a field for a reviewer to mark that they are interested in reviewing this addon in the future (if it's not already taken by someone) and then when a new version is submitted, they get an email

It might be handy to include the version notes available too, so reviewers don't have to search for them. Most updated extensions are not very different than their predecessor, but only add something (like locales etc.). --Electronical 04:44, 31 August 2006 (PDT)

Myk: one possible defense against the gaming of user ratings is to allow users to identify others they trust (à la social networking sites) and then weight user ratings according to the length and strength of the trust chains which link them to a set of seed users whom we consider eminently trustworthy.

EE: This kind of trust network has been investigated by Advogato.com; it seems to work fairly well. There's a deeper description of algorithms for it there.

For each of these metrics you could also ask the question, how does this version of the extension's metrics compare to the previous version's metrics? (or the average metrics over the lifetime of the extension) to find out if the latest version is better or worse than the previous one.

This could be displayed on the extensions page in some way so that people can have some idea of how desirable it is to update to the latest version as well as being used to create a "most improved" or "top movers" list.

If there was a significant drop in quality a link to the previous version could also be displayed under the install button, although it might be best if that was triggered by an editor as it wouldn't take into account effects like negative reviews when an extension isn't compatible with the latest version of Firefox.

--Sam Hasler 15:41, 23 November 2006 (PST)

shaverthoughts(tm)

I'd love to see the AQ die, or be something where N "random people" can review to ensure that the description is good, the policies are followed, and it's not obviously a scam or abuse of some sort.

For the "stamp of approval" cases, I think that our current crop of reviewers include a number of the right picky-and-thorough type of people. Add-ons could be "nominated" for a fuller review to become part of the "top tier".

I'd also like to see a way for updates to be pushed out automatically by the developer, perhaps via a per-developer or per-add-on flag to permit that streamlining.

Screenshots

Starting with Remora, every extension page should be 'required' to include at least 1 screenshot of their extension in use. If an extension author can take the time to create an extension, test it, and upload it to AMO then why is it that so many don't bother taking the time to take a screencap (and include it in their extension description submission)? Words are good but pictures give a much more immediate idea (or help visualize exactly) what the extension achieves. I propose that at least 1 screenshot be made a mandatory requirement of submission/approval. No screenshot, no approval. RenegadeX 09:53, 19 December 2006 (PST)

Self-Promoting SPAM/BUMP updates

One major annoyance on AMO is seeing the same extensions constantly (daily/almost daily)in the 'Most Recently Updated' list -- when everyone and their dog knows that the extension has NOT been updated.. the author is intentionally 'bumping' their extension to the top of the list. The 2 biggest culprits must surely be the Mojabosna Toolbar and the Reel New Media Toolbar. What can be done to prevent authors from claiming to have updated their extension just so they can always stay near the top of the list? Not saying that this is what these guys do, but an author could add or remove a blank line from their code every single day and claim it was 'updated'. It looks bad on AMO. RNMtoolbar currently has a rating of 0.31 -- AMO needs a special section for extensions (and authors) such as these --- "The Shitter. Enter at your own risk". RenegadeX 10:03, 18 September 2006 (PST)

I would prefer to see extensions that abuse this system and others (such as manipulation of the rating by posting many self-serving positive comments and removing negative ones) removed completely from the AMO site, but as a minimum they definitely need to be kept separate from the main extensions. --Andy tech 19:19, 24 November 2006 (PST)

EULA/PP localizations

If we support EULAs/PPs, we would either a) require someone that doesn't speak english to accept something they can't read or b) require an extension author to get the length EULA translated into all of our supported locales and either put into the install.rdf or use a special interface we make. Fligtar

Typically, the English version is the normative one, and translations are provided as a non-binding courtesy one. That's the case with the Firefox EULA, for example. Shaver 06:34, 15 August 2006 (PDT)

Dictionaries

The Firefox and Thunderbird clients have support for MySpell dictionary extensions. Currently the client treats a dictionary extension like any other extension, but the administration requirements may be unique:

There should be one official dictionary per locale.
It should be maintained by the l10n team that maintains the client locale
Because myspell does not support aggregating multiple dictionaries, there is little reason to support specialized (architecture, chemistry) dictionaries.
For locales that do not ship a dictionary by default in the client (due to licensing issues), the major AMO entrypoints might feature a "Install German dictionary" link.
The clients have an AMO entry point in the "Get More Dictionaries..." context-menu item in spellchecked textareas
- A simplified UI to install available dictionaries might look like the Tbird 1.5 install page: http://www.mozilla.com/thunderbird/dictionaries.html
Extensions for online services that provide dictionaries should probably be treated separately from myspell dictionary extensions

Which of those are actual requirements? Providing an English "basic + computing" dictionary seems like it could be worthwhile, even if myspell sadly can't aggregate for us (yet?). If such a dictionary appears and is useful, is it a requirement that we not post it? Or not post it as a "dictionary"? Shaver 16:46, 20 August 2006 (PDT)

Also: would we permit variant dictionaries for locales that we don't ship, such as en-CA (as distinct from en-GB and en-US)? Who would sign off on those, in the absence of a l10n lead for that locale? Shaver 17:43, 20 August 2006 (PDT)

Site banner/identity

Can we just have one banner for the whole site, instead of the silly app-spefic banner? I've seen the app specific one on the mockups and it gives me nightmares. Splitting the site by app causes problems when we want to add new apps, and search doesn't work properly, and we want to get the app parameter out of urls because it's silly, but then how do you say "hey check out this great thunderbird theme" and link your friend to it? I think it's a bad idea overall. Cameron 09:51, 22 August 2006 (PDT)

User accounts

Can we use only one database of accounts for the dev cp, forums, reviews and whatever else please? It's soooo much nicer. Cameron 09:51, 22 August 2006 (PDT)

Mark O'Sullivan (creator of the forums we'll be using, has said that it is possible to integrate with our existing sessions and users, so you won't have to login specifically to the forums or anything, it will all be the same login. Fligtar 18:48, 22 August 2006 (PDT)

Automatic Log-in Option

Why oh why in this day and age is AMO one of the few sites around that have no option to automatically log a user in whenever they are visiting the site? It is an unnecessary inconvenience to have to click 'Log In' every time I visit and wish to install an Experimental add-on, rate an add-on, or leave feedback (the last 2 are grayed-out unless you are logged-in).

It may only take a few seconds to do, but it seems to me that considering the many thousands of weekly downloads most good extensions get, the low number of reviews left suggests that people simply aren't bothering to log-in. So not only would an automatic log-in option be a time-saver, but it would benefit the site, the developers who have put in their hard work, and the users who are looking for good feedback on add-ons as they are browsing.

Ideally, it should be a set-able option available under My Account, but how could it be made discoverable (so that most users can enable it)? --RenegadeX 00:42, 9 June 2008 (PDT)

Licensing

It would be great if each addon had a link to the licence or licenses it was available under, and to the source if the licence requires that distributors such as a.m.o. make it available. I believe we don't have a licensing policy for a.m.o, so it's all the more important to a) make it clear, and b) comply with whatever the licence is if it has things to say about distribution. Gerv 14:09, 23 August 2006 (PDT)

It's planned to have developers able to specify an EULA, and also for them to be able to use html in the developer notes about the add-on, so they could link to their source code there - is that enough? Cameron 08:02, 24 August 2006 (PDT)

If you count the people who are asking for maintaining an "abandoned" extension, this is a very vital question because with the right license, a new fork could be started easily (and not and no more questions about if the license doesn't allow that). Archaeopteryx 10:34, 23 November 2006 (PST)

Search

In my opinion, AMO is in need of an overhaul. There are so many good extensions out there, but finding them on AMO is difficult - for a number of reasons. A number of individual Bugs have long-been filed suggesting improvements for the site, but until the problem is attacked from a 'big picture' perspective, I don't foresee the site reaching its full potential. I filed Bug 349430 to address the issue, and listed the 3 major problem areas and some considerations that need to be met in order to make AMO a user-friendly site. RenegadeX 21:16, 25 August 2006 (PDT)

As mentioned on that bug, simply stating "it's not good how it is" is not helpful. If you've got any individual behaviours you'd like to suggest or discuss, please feel free to do so. Everyone working on Remora is already aware of the existing bugs. Cameron 07:07, 31 August 2006 (PDT)

^ My Bug post identified issues and gave suggestions for remedies - do *you* have any comments, Cameron? Everyone working on Ramora (or AMO) might be aware of what is going on behind the scenes to improve AMO but certainly nobody else does. Current status? Is there a plan and a progress report somewhere? RenegadeX

I hope to get my blog on planet shortly at which time I hope to blog regularly about Remora development. For now, you can look at Update:Remora_Dashboard and Update:Remora_Meeting_Notepad

I think your bug has a lot of good points (that we all agree with). I'm currently writing the search for remora, and at this point it just does a basic LIKE query, but it will be easy to expand on, it just depends on how creative we want to get. I think your #2 and #3 issues from that bug are the highest priorities (in respect to what I'm doing right now). If you have experience with php, you're welcome to see the search() function evolve here (and i'm happy to hear suggestions). Since it's working right now in it's most basic form, I'll start focusing on enhancing it (sorting results, creating an advanced view, etc.). In fact, I'll just start a "basic flow of search" section in the idea dump as soon as I finish posting this. -- clouserw

^ I have a basic(or BASIC!) understanding of code, so I can see what's happening, but until I see it in action, it's hard for me to visualize the final result. If you have a working test-page at any point in time that you want feedback on, I'll be more than happy to give my input. RenegadeX 20:51, 7 October 2006 (PDT)

One of my gripes would be that its hard to find multiple words. For example, 'Restart Firefox'. Google for ""Restart Firefox" site:addons.mozilla.org", an extension called Restart Firefox is #1. Search on AMO and its #17. This causes problems for authors who didn't choose a single-word name for their add-on. There are multiple issues here: there is no way to search for a phrase, the score for a search result doesn't go up if the terms appear in order, theres no word stemming... adding support for phrases is doable with your sql backend, but incorporating a 'real' search engine would cover all of the issues. Bazzargh 06:58, 1 November 2006 (PST)

When browsing search results or categories the descriptions of some extensions are too long, requiring excessive scrolling, could the description be limited to a summary of 25 lines maximum (preferably less). --Andy tech 21:53, 25 November 2006 (PST)

Basic flow of search

This will probably grow greatly after our next meeting, but throw some ideas out:

By default (ie. not an advanced search):
- We'll search Addon.name, Addon.summary, Addon.description
- Occurrences will be weighted (exact title match, match in title, match in summary, match in description.
- Results will be returned in a "relevance" order

Ideas for making the search better (we can play with these):
- Remove common terms (eg. 'the' or 'to')
- split terms, unless they are quoted (eg. when searching, 'x y' becomes '%x%y%' instead of '%x y%')
- how crazy do we want to get with this? Do we want to key off AND and OR too? Too bad lucene's not ready for this :(

--wonder if there is a way to factor in a metric that expresses one or more of user rating/active user count/recent download count to play into relevance? --chofmann

I agree that the current search returns to many results and some poor matches. From post above :

- Occurrences will be weighted (exact title match, match in title, match in summary, match in description.

This is a good idea and an important feature IMHO.

It would also be good to have an exact phrase match (" ") and include/exclude (+/-) options for the search. Also in advanced search options, tick boxes for where to search for text, in : title, summary, description.

Searching by compatibility would be good too, there are a number of extensions which have not been updated for firefox 2.0. Is is possible to have an option box to search for compatible extensions only, either manually selecting or auto-detecting browser version. --Andy tech 18:26, 24 November 2006 (PST)

I second Andy tech. It is very frustrating to find an extension that looks interesting, only to discover after yet another click or two, that it works only on, for example, Version 2.0 or above. I'm not sure how best the choices should be worded, but the idea is that if somebody is using 1.5.x, they won't see any extensions that don't work on 1.5.x The levels should be at least at major intervals (i.e., 1.0, 1.5, 2.0) although minor levels would be nice, too.

Sorting of addons

If you look at the distribution of downloads between the first page (top 5), the extensions page (top 6-10) and the second "popular extensions" page (top 11-20) - there is always a ~50000 downloads gap in between. It is only natural that people find extensions on the first pages more easily but there are two problems here. First: once an extension manages is to the first page it gets more downloads and tends to stay there. Consequently the extensions on the first page aren't necessary the best extensions but rather the ones that got lucky (or got there early enough). Second: it seems that 50% if not more of all downloads are people who get to AMO looking for the "best" extensions and download whatever they find on the first page, regardless of whether they need it or not. At least that's what traffic stats on adblockplus.org indicate - they haven't changed a bit after download numbers doubled due to Adblock Plus being in the top10 (analyzing AMO's web logs would tell for sure of course). Those are probably also the people who will immediately blame Firefox for any issues they run into.

Consequences:

Sorting should never be done by download numbers since the download numbers of the addons on the top only tend to increase - this discriminates newer addons
It is vital that any specially promoted extensions are of good quality (and being displayed on the first page is such a promoting)

Metrics have been mentioned above and I think the one relevant here is QA approval. I would go as far as saying that no extension without QA approval should be displayed in a prominent position. And by this I mean that those extensions should really be tested thoroughly, somebody should look for anomalies in the source code (typical examples: replacing browser's built-in methods instead of extending them, using own versions of built-in XBLs, explicitely unwrapping content nodes). And the review will have to be repeated regularly (after X months, after X releases?).

I am not sure whether "approved" addons should go first in other lists as well. In any case, they should be clearly marked - this will encourage authors of less popular addons to meet the requirements as well.

Secondary sorting criterium could be rating - morgamic seems to think that he can get the ratings meaningful enough for that.

--Wladimir Palant 14:22, 1 September 2006 (PDT)

The sort of power law distribution that you describe is perfectly natural in this instance. Fighting against it by "never" sorting by "download numbers" is counterproductive, and it's an oversimplification to say that once someone is lucky enough to get into the top five they are going to stay there. In my mind the two problems are 1) a lot of the most downloaded have a surprisingly high (and consistent) level of downloads, leading me to suspect that they are gaming the system and 2) the sorting by rating is far too simplistic, as has already been stated.

-- Plasticmillion 10:45, 1 November 2006 (CET)

Even sorting by ratings there is still likely to be some bias towards extensions that already have a high rating. To combat that you could have a "most improved" or "top movers" list that show extensions that might be father down the list but have started to move up it. This would allow updated extensions to more quickly settle to a more appropriate rating. To be of any use it should only take into account a limited date range, so if no extensions were updated in a while, and the relative rankings didn't change then the list would be empty.

--Sam Hasler 15:28, 23 November 2006 (PST)

Airbag Integration

It would be nice if extension authors with binary components can optionally upload their symbols (.pdb files in the case of MSVC) too, to appear as part of crash stacks. Currently if a crash involves a binary component we get no stack, and so it's difficult to track down the crashes.

-- Mook 04:29, 28 October 2006 (PDT)

This would be fantastic.

-- Plasticmillion 10:47, 1 November 2006 (CET)

Comments

The current linking of comments and ratings is very problematic. We (AllPeers) have had a significant problem with trolling, and it would be nice to give the trolls a way to vent their spleens without basically forcing them to give a zero rating. Also, we get frequent requests for technical support in the comments, with no good way to reply to them.

What is needed is a threaded comment section that is completely independent of the ratings.

-- Plasticmillion 10:50, 1 November 2006 (CET)

Approval / Action log

UI for the action log describes some ideas for Bug 255305, I have some code for this.

Beta/Preview site

I pray that the new version of the site won't be launched suddenly on the unsuspecting public in the way that the last AMO update was (coinciding with FF2.0's release). There was a MozillaZine thread at the time filled with a torrent of criticisms of the 'improvements'. I strongly suggest, and urge - a working Beta or Preview site be made available to the public (perhaps via a link on MozillaZine forums) well in advance of Remora's launch so that a repeat can be avoided. As I indicated in an earlier comment, it's all well and good to see plans and code snippets being made available but it's another to be able to actually visualize it - and use it so that useful feedback can be provided. Though some of us may be negative and critical, we all want the best for the site, and fellow Mozilla-product users. RenegadeX 09:02, 2 December 2006 (PST)

Update: There is now a Preview up at http://preview.addons.mozilla.org/ and a Feedback page at http://wiki.mozilla.org/Update:Remora_Feedback

RenegadeX 00:33, 6 January 2007 (PST)

Installing Thunderbird add-ons

(Note: I'm not all sure, if this fits here, so if not, please excuse and correct me.)

Right now, there is this template (for extensions): <example>

How to Install in Thunderbird: 
  1. Right-Click the link above and choose "Save Link As..." to Download and save the file to your hard disk.
  2. In Mozilla Thunderbird, open the extension manager (Tools Menu/Extensions)
  3. Click the Install button, and locate/select the file you downloaded and click "OK"

This process can be shortened, as one can paste the Link URL in the file-selection-dialog (in Thunderbird extension manager). So temporarily saving it on hard disk by hand is superfluous overhead.

(Of course, even better would be auto-detecting Thunderbird extensions (or better: more generally add-ons) and passing them on to the Thunderbird application for handling/installing there.)

Greetings, -- Atmozphere 13:19, 17 March 2007 (PDT)

Graphs

As a Remora user (i.e. extension developer), I found graphs to be a great tool to monitor my (relatively unpopular) extension's exposure, and I believe that would be very much appreciated by other developers as well. The purpose of course is to help developers maximize their extension's exposure by allowing them to evaluate what gives them best leverage for exposure -- and access to historical data is an essential tool in that regard.

I made a proposal half a year ago in that direction by writing the Remora Stats article, and I received no feedback. I can certainly accept my idea might not be practical to implement for whatever reason, but as an extension developer I cannot accept it's completely idiotic and not deserving any attention whatsoever.

Please take a minute to review it, check out my own implementation of that idea for my extension, and give me the minimal courtesy of dropping a line in the discussion page, time permitting.

Cheers, --BogdanS 14:29, 18 May 2007 (PDT)

Update:Remora Idea Dump

Contents

Approval Queue

Metrics

shaverthoughts(tm)

Screenshots

Self-Promoting SPAM/BUMP updates

EULA/PP localizations

Dictionaries

Categories

Site banner/identity

User accounts

Automatic Log-in Option

Licensing

Search

Basic flow of search

Sorting of addons

Airbag Integration

Comments

Approval / Action log

Beta/Preview site

Installing Thunderbird add-ons

Graphs

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

How to Contribute

MozillaWiki

Around Mozilla

Tools