Life of an Editor on AMO

Recently I’ve seen a large number of add-ons get nominated for public on addons.mozilla.org (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.