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)

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.

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

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)

URLs

I want to get rid of all the cruft. I don't want to see a single .php anywhere. Atm we have faq.php, support.php, etc. etc.

I want

/addon/1234
/addon/1234/previews
/author/321
/developer
/developer/myaddons
/developer/myaddons/new
/developer/myaddons/update
/admin/usermanager
/admin/appmanager

etc. etc.

(they're just ideas for the urls btw) Cameron

With cake, it's pretty much guaranteed you won't see .php anywhere. Also, because of the models, there will be very very few pages that aren't associated with a table. For adding/updating/managing addons, the url will be addons/add or addons/manage. The only thing in /developers will be a listing of your addons with links to the other models. For admin stuff, it will be a page with links to the administrative things for the various tables, like tags/manage. Obviously, this will all be controlled with cake's ACL so not anyone can access these features. Fligtar 18:46, 22 August 2006 (PDT)

I think that /addon/addon-name/ or even /addon/1234-addon-name/ is better than /addon/1234/ /author/321-john/ or /author/john/ is also better than /auhor/321/ Tbassetto 01:14, 23 August 2006 (PDT)

Sure, but I think we've been through this before and it creates problems if the add-on's name changes... Since it's all done through .htaccess anyway I suppose it could just match both the addon's current name and it's old name/s with the ID, if we added old add-on name info to the db... that's ugly though. - Cameron

Yeah, it's not practical, especially in the presence of names containing non-ASCII characters. Shaver 11:30, 30 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)

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)

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

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

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)

Update:Remora Idea Dump

Contents