Add-ons/Reviewers/Guide/Tools: Difference between revisions

From MozillaWiki
< Add-ons‎ | Reviewers‎ | Guide
Jump to navigation Jump to search
m (Minor formatting)
(Review actions)
Line 21: Line 21:
History entries can have Version Notes and Notes to Reviewers. Version Notes are meant to be public, while Notes to Reviewers are meant for us reviewers only. They can include testing information or responses to previous review notes. Since testing information isn't usually version-dependent, we prefer to have those in the Whiteboard field, which you can find at the bottom of review pages. This is a shared field between the add-on developer and the review team, so make sure that testing info is always there and up to date.
History entries can have Version Notes and Notes to Reviewers. Version Notes are meant to be public, while Notes to Reviewers are meant for us reviewers only. They can include testing information or responses to previous review notes. Since testing information isn't usually version-dependent, we prefer to have those in the Whiteboard field, which you can find at the bottom of review pages. This is a shared field between the add-on developer and the review team, so make sure that testing info is always there and up to date.


== Resolutions ==
== Review actions ==
Near the bottom of review pages you should see a list of review actions:
[[Image:Resolutions.png|center|Possible review resolutions]]
[[Image:Resolutions.png|center|Possible review resolutions]]
Clicking on any of them will open a form below it.
The comments textbox is where you should write all of your review notes. There's also a canned response list below it, that contains very useful, reusable snippets of text for your notes. Selecting any of them will just add the text to the textbox. You can use as many as you need.
The first 3 actions will resolve the pending review:
* '''Push to Public:''' the version doesn't have any major problems and it's OK for the public (full review). This option won't appear for add-ons only requesting preliminary approval.
* '''Grant/Retain Preliminary Review:''' the version doesn't have any security issues. If this version is pending full review, preliminary approval also means it has other non-security issues that prevent it from being public (full review).
* '''Reject:''' the version has security issues and must be rejected.
Once a review is submitted, an email including your notes will be sent to the add-on developer. Developers can respond to your review via email, and an admin reviewer might loop you in the discussion if it requires your attention.
The other 3 actions are used on special situations:
* '''Request More Information:''' this allows you to ask the author for information necessary to perform the review, without removing the add-on from the queue. A very common case for this is when the add-on is site-specific and the author didn't provide a test account.
* '''Request super-review:''' this is for cases when you think an admin reviewer should give this add-on a look. Use it for add-ons that appear suspicious or you don't think a regular reviewer can handle. The add-on will remain in the queue, and the developer will be notified, but your notes aren't sent as part of the notification. They're only readable to other reviewers.
* '''Comment:''' this allows you to add a comment that is only readable by other editors. It can have testing information, partial notes that you had from reviewing a version that you couldn't finish, etc.

Revision as of 19:57, 19 January 2015

The Review Queues

The review queues look like this:

Queues.png

The add-on name and version number are links to the review page for each add-on. They are blurred in the image to protect the developers' privacy. A lock icon will appear to their left if another reviewer is looking at that add-on. In the Flags column, hovering over any icon should tell you what it means. The last icon in the column (white page with a pencil) shows you the Version Notes and Notes to Reviewer if you click on it.

You will usually see many add-ons near the top of the queues that have been waiting for very long times. They are usually flagged for admins or are waiting for something to happen before they can be handled. Skip those and focus on the add-ons near the middle or bottom, especially if you're only getting started. You can work your way up as you become more experienced.

Review Pages

The top of review pages look just like the top of add-on listing pages, including all the information provided to users about the add-on. Below the add-on description is where the review-specific information appears.

First, there might be an "Add-on user change history" section. This lists all the ownership changes this add-on has had, if any. This is important because an add-on changing hands could mean that the new owner will include vastly different features or monetization to the add-on. Be careful when reviewing add-ons that recently had ownership changes.

Then there's the Add-on History:

Review page

This shows the most recent versions and their review resolutions. This is very valuable information when reviewing an add-on. You need to make sure that issues brought up in the last reviews have been addressed. The last 3 are shown by default, but you can click on the previous ones to expand them.

The All Platforms link points to the file to review, generally an XPI. The Validation link will run the automatic code validator on that file and show you the results. The Contents link opens the source code viewer, and the Compare link opens the diff viewer, so you can compare the current version with the previous ones.

History entries can have Version Notes and Notes to Reviewers. Version Notes are meant to be public, while Notes to Reviewers are meant for us reviewers only. They can include testing information or responses to previous review notes. Since testing information isn't usually version-dependent, we prefer to have those in the Whiteboard field, which you can find at the bottom of review pages. This is a shared field between the add-on developer and the review team, so make sure that testing info is always there and up to date.

Review actions

Near the bottom of review pages you should see a list of review actions:

Possible review resolutions

Clicking on any of them will open a form below it.

The comments textbox is where you should write all of your review notes. There's also a canned response list below it, that contains very useful, reusable snippets of text for your notes. Selecting any of them will just add the text to the textbox. You can use as many as you need.

The first 3 actions will resolve the pending review:

  • Push to Public: the version doesn't have any major problems and it's OK for the public (full review). This option won't appear for add-ons only requesting preliminary approval.
  • Grant/Retain Preliminary Review: the version doesn't have any security issues. If this version is pending full review, preliminary approval also means it has other non-security issues that prevent it from being public (full review).
  • Reject: the version has security issues and must be rejected.

Once a review is submitted, an email including your notes will be sent to the add-on developer. Developers can respond to your review via email, and an admin reviewer might loop you in the discussion if it requires your attention.

The other 3 actions are used on special situations:

  • Request More Information: this allows you to ask the author for information necessary to perform the review, without removing the add-on from the queue. A very common case for this is when the add-on is site-specific and the author didn't provide a test account.
  • Request super-review: this is for cases when you think an admin reviewer should give this add-on a look. Use it for add-ons that appear suspicious or you don't think a regular reviewer can handle. The add-on will remain in the queue, and the developer will be notified, but your notes aren't sent as part of the notification. They're only readable to other reviewers.
  • Comment: this allows you to add a comment that is only readable by other editors. It can have testing information, partial notes that you had from reviewing a version that you couldn't finish, etc.