278771 - Simplify approval queue

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Developer Pages, defect)

Description

[alanjstr]

The approval queue requires a lot of manual input.

I'd like each block to be have the checkboxes removed and rearrange the radio
buttons so that it looks like 

o Approve o No Action o Deny [DENIAL REASON]

Can we assume, for the sake of actually getting things approved, that someone
will only approve a submission after they've tested it, without having to check
off each item they tested?  I think this is a major usability improvement.

Comment 1

[alanjstr]

Attachment: Screenshot of the approval queue

Comment 2

[Chris Beard]

No.  It is *very* important that there be some process by which Extensions and
Themes get approved for inclusion on mozilla.org.  In fact, we need to revisit
this and come up with a formal checklist aligned with a set of policies about
what Extensions must do (i.e. display a privacy policy if they use handle
end-user data in certain ways), and must not do (i.e. anything "evil"), in order
to be hosted by us.  This should be added as an agenda item for our next meeting.

Comment 3

[alanjstr]

I don't object to having a process, I object to having to type and click a lot.

We have more than 140 updates that people are ready to submit.  I want Editors
to spend their time testing, not filling out forms.

Comment 4

[Nickolay_Ponomarev]

I would not remove the OSes and applications fields. A single person might not
be able to test with all apps/OSes and the fact that extension doesn't break
Firefox does not guarantee it won't break Thunderbird or Mozilla. And there are
a few issues with extensions/themes that show up on Linux only (that Windows
authors just don't notice).
About checkboxes - I agree with Alan (if anybody asked me). Test it well or not
at all.

Comment 5

[Wolf [:wolf]]

Nice to see you're still trying to gut UMO of its acountability. You need to
have respect for the situation that exists regarding what UMO tries to do, and
not just how much you have to type and click.

Comment 6

[Wolf [:wolf]]

The checkboxes would be more useful if they were stored for the record
incrementally. Allowing multiple editors to work on the items in different
areas. It'd also distribute load and allow editors to devote less time and save
their work to the system.

To acheive this, the t_approvallog records simply need to be managed
differently. Currently the queue uses mostly inserts and doesn't allow that
insert of the full completed record to take place unless its complete. Instead,
it should be able to insert or update, but simply disallow making as approved
until its complete.

Comment 7

[Jan Dittmer]

Couldn't you move the os and application field to the top of the queue? normally
when you approve, you approve items together which you checked in the same
application/os. that would make a) the list shorter and b) remove some tabbing.
And please remember the last filled in os/application when you're at it. they
don't change that much.

Comment 8

[Cameron]

(In reply to comment #7)
> Couldn't you move the os and application field to the top of the queue? normally
> when you approve, you approve items together which you checked in the same
> application/os. that would make a) the list shorter and b) remove some tabbing.
> And please remember the last filled in os/application when you're at it. they
> don't change that much.

Or simply just detect application and OS from user agent string.

Comment 9

[alanjstr]

> Or simply just detect application and OS from user agent string.
Unless you're testing a non-browser thing, like TB.

Comment 10

[Cameron]

How about if the apprival queue was:

[Addonname] - [addonversion]. By [authorname]. Submitted on [date]. Works with [applications and versions] 

and that was it. 

Then when you click on it, it takes you to a longer page specifically about that addon. List of previous versions, addon description, version notes, preview images, previous approval/denial comments (Bug 335373), if the addon is already listed, we should display the addon's rating and have a link to the addon's listing page, also should have link to extension's/author's homepage, link to search for addon's name on bugzilla, link to search for addon's name on mozillazine. If the author doesn't have a homepage, link to search for addon's name on google. 

Then there should be a link to the wiki page about how to test addons.
Then a comments to developer field and then two buttons - approve and deny.  

In this way, the approval queue would be far simpler and take far less time to load, but on the other hand, reviewers would have far more information at their disposal when approving or denying.

Comment 11

[Cameron]

AMO bugspam. Correcting QA contacts on OLD bugs ([e-mail])

-> Correct QA contact ([e-mail])

Filtermeplzkthx

Comment 12

[Mike Shaver (:shaver emeritus)]

I'm going to say this is FIXED based on fligtar's DHTML work.