531875 - Sort review queues by original submission date

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Admin/Editor Tools, enhancement, P3)

Description

[Jorge Villalobos [:jorgev] (he/him)]

This may be a dupe, but I couldn't find the original. 

The current sorting mechanism is unfair to authors that frequently update their add-ons, or have to go through several review cycles before their add-on is approved. We should favor those who have been waiting the longest.

Here's the proposed sorting mechanism:
1) For nominations, sort by the first nomination date.
2) For updates it's trickier because it should be the date of the last unapproved nominated update *after* the last public version.

If (2) is too hard to implement, I think it can be safely ignored, given that updates are reviewed rather quickly. (1) is very important, though.

Comment 1

[Wil Clouser [:clouserw]]

Jorge, can you be more specific about #1 and #2.  I thought #1 was about nominating multiple versions while they are still in the queue and fligtar was saying something about a version that is denied and then reuploaded keeps the original date?

Comment 2

[Jorge Villalobos [:jorgev] (he/him)]

There are 2 situations we want to resolve:

1) When an add-on is being frequently updated and each new submission goes back to the end of the queue.
2) When an add-on is rejected and resubmitted multiple times, every time going back to the end.

I want to eliminate both of these, and instead allow the new submissions to regain their old position. This will be unfair in some cases, like those of authors that have faulty add-ons and are constantly being rejected by us. I'm not too worried about that considering the benefit it will have to others.

Comment 3

[Wil Clouser [:clouserw]]

ok, we'll look with the new dev tools

Comment 4

[Axel Grude [:realRaven]]

(In reply to comment #0)
> This may be a dupe, but I couldn't find the original. 
> 
> The current sorting mechanism is unfair to authors that frequently update their
> add-ons, or have to go through several review cycles before their add-on is
> approved. We should favor those who have been waiting the longest.
> 
> Here's the proposed sorting mechanism:
> 1) For nominations, sort by the first nomination date.
> 2) For updates it's trickier because it should be the date of the last
> unapproved nominated update *after* the last public version.
> 
I think (2) would be great (as I am a frequent updater), but hard to solve automatically. If it was based on the first release date after the public version (easy algorithm to implement), it could easily be abused e.g. by releasing a version bump immediately after review. I am afraid its difficult to determine whether an update contains a crucial bugfix or much awaited features - you'd almost have to review user feedback for this... 

Maybe it would be possible to show an abridged version of the dev. notes on the queue to make the decision process easier. Also the number of unreviewed versions since it went public is a good indication of whether there is "busy schedule".

Comment 5

[Wil Clouser [:clouserw]]

fixed with new tools