Reviews on AMO

My last post keeps getting comments, and I’m seeing this brought up on the amo-editors mailing list a lot. Add-on authors have two big questions:

  1. How do I get reviews for my add-on?
  2. Do external reviews count?

These are both very good questions, but sadly, I haven’t seen a really good answer to either yet.

How do I get reviews for my add-on?

All you have to do is get people to post reviews to your add-on in the sandbox. Yes, there is a slight barrier to entry with this process since AMO requires users to first sign up and then enable the sandbox before they can even post a review. This process is still being smoothed out by the AMO developers (last I knew), so things may get a bit easier. One of the editors has written up a wiki page with directions on how to post a review that you can link your users to.

There are a number of ways in which you can obtain reviews for your add-on. If you extension is site-specify, post on that site about it, and get the users interested in it. If it targets a specific group, perhaps you should reach out to that group through a mailing list or forum. Blogging is quite popular these days, so blog about your add-on; get your friends to blog about it! Perhaps we should start a wiki page and let add-on authors share how they are getting the word out about their add-on.

Do external reviews count?

They certainly can in my book! The catch is that editors are not likely to go out looking for them, so you should absolutely provide URLs to them in your notes to the review section when nominating your add-on for public status. If you don’t provide links, you should expect that we won’t find them.

I hope this clears things up a bit. If you have any questions, feel free to mail the editors list (amo-editors at mozilla dot org) or post comments here.


Neat Bugzilla Feature

Did you know you can mark bugzilla comments, making them appear to be highlighted? timeless recently pointed this out on irc, and I figured a lot of people didn’t know about this really neat feature. All you have to do is add &mark={comments} to the query string of the url, and can you can highlight away! The comments can be specified in a comma separated list, and/or you can specify ranges.

I’ve marked up my first fixed bug as an example.


SQLite in and back out

I landed the upgrade to SQLite today to get us up to version 3.3.17. The version in trunk is horribly old, so we really need this upgrade. Sadly, Windows didn’t like it and the patch is now backed out again :(

Hopefully I’ll get a patch tomorrow that doesn’t hang on shutdown. Now, I’m off to go play in the land of multi-threaded code – hurray!


More Download Manager Changes

Two more download manager back-end changes landed recently. First, Bug 382825 added a potentially useful method:

void retryDownload(in unsigned long aID);

This will retry a download with the specified id, and fails if it cannot find the download in the database or if the download is currently in progress.

Then Bug 382839 landed, which enables getDownload to return both active downloads and any download that is in the database. Extension authors will not have to directly query the database to get the information they need about the download.

I think this is probably about it for back-end changes for Firefox 3. Still fixing a few random regressions that have popped up, and an interesting leak was found, but otherwise, it is about time to move onto the UI overhaul!


Life of an Editor on AMO

Recently I’ve seen a large number of add-ons get nominated for public on (AMO) that didn’t meet some of the basic requirements that an author is supposed to meet. I thought it might be a good idea to let add-on developers know what it is that I look for when I take a look at the public nomination queue. Hopefully they’ll stop nominating things that don’t meet the requirements.

  1. Does the add-on have any reviews from its users?

    AMO requires an add-on to have reviews from its users for it to even be considered for public nomination. Without reviews, we editors cannot effectively do our job. This is the most common reason that I have seen for an add-on being denied in the public nomination queue.

  2. Are the reviews for the add-on simple, or are they more like a technical review?

    Reviews such as “This is a great extension!” or “This theme looks really nice” are not very helpful. These type of reviews do give me an idea on how useful people think your add-on might be, but that is not enough for public nomination. If an add-on only has a few reviews, and they are like those two examples, I’ll often be inclined to retain the add-on in the sandbox.

    The reviews that I really look for are people who install the add-on, test it, and report their findings. A report on a broken feature, with the platform (Windows, OS X, Linux), application (Firefox, Thunderbird) and its version, and the version of the extension is an awesome review. Reviews that go over what the reviewer tested and what they liked and didn’t like (with some details) are just as useful. If there are a few reports about a broken feature, I’ll be inclined to retain it in the sandbox and indicate that to the author. However, if there are enough favorable technical reviews, I’ll continue the process.

  3. Is the author responsive?

    If there are discussion posts associated with the add-on, I like to check and see if the author is responding, or is essentially ignoring them. If it has been several weeks since a post was posted, and still no response from the author, I’ll be inclined to retain an add-on in the sandbox, as per the AMO policy. If there are no discussion posts, I’ll look to see if there is another place where the author distributes the add-on and see if there are posts there. Same guidelines apply. If the author seems responsive, or there are no posts to be found, I move on to the next step.

  4. Is the add-on clearly and accurately described?

    I’m not going to deny you for a typo, but if your description is false or too vague, you’ll have to fix that and then re-nominate. If you add-on has had a few versions released, I’ll look at version notes and see how well you update them. I won’t deny it again for poor version notes, but I will make a note of it in the comment, and expect you to fix it. Editors will look at it next time you submit a version and ensure that you are doing as you are told by other editors.

  5. Are all privacy and security concerns clearly spelled out?

    This one is really simple. If the add-on is sending user data over the internet, it will probably need some sort of privacy policy. If the add-on doesn’t do that, it’s best to leave the field blank because AMO will have a warning that you have a privacy policy right next to the install button, and this could scare users away. Same thing goes for the EULA.

  6. Is the add-on free of unlicensed trademarks or copyrights?

    The policy page is pretty clear about this. AMO doesn’t want to host anything that violates anybody’s trademarks or copyrights, so please don’t nominate it.

  7. Do the add-on and add-on author both treat the user respectfully?

    If you add-on starts installing unnecessary software, forces its toolbar to be always visible, or other things that are not respectful for the user, it will be kept in the sandbox. Your extension should be a good citizen in the application you target and provide the user with options to turn off features if they choose to do so (this is highly subjective and not always necessary).

  8. Has the add-on been well-tested, and is it free of obvious or serious defects?

    This is probably the most time consuming part of the editing process for me. After I install the add-on and restart my browser (or Thunderbird if I’m testing an add-on for it), the first thing I check is for any errors or warnings in the Error Console. I have the ConsoleĀ² extension which allows you to enabled strict warnings and filter errors and warnings so you only see the ones from chrome code. I strongly recommend every add-on author to check their work with this before nominating it for public. Warnings are generally OK, but we expect the number of warnings to go down with each release (not up, nor staying constant). Errors all depend on what the error is, and if it breaks functionality. Those, however, I expect to be fixed in the next release of your extension.

    Now I’ll start to play with the functionality of the add-on, keeping the error console visible so I can see if normal use triggers any warnings or errors. If things are working as advertised, this add-on is one step closer to being approved. If not, I evaluate each issue on a case by case basis as to whether or not this issue is something that should keep the add-on in the sandbox.

    Finally, I’ll start to look at the source code of the add-on. What I am looking for here is basically glaring mistakes in the code, potential conflicts with other extensions, and privacy and security issues. Any one of these issues is enough to keep the add-on in the sandbox, but I always make sure to state how to go about fixing the code so the author can do so quickly and renominate.

If the add-on makes it all the way through that, it will be approved, and I get to move on to the next one.