434048 - Implement way to moderate problematic reviews

Status: VERIFIED FIXED

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

Description

[Fred Wenzel [:wenzel]]

When we auto-approve reviews (bug 428535), we will need a way for problematic reviews to be marked as such and put into the review queue for editor moderation.

My thoughts:
- we should add a link along the lines of "report this review" (possibly allowing to mark it "inaccurate" vs. "inappropriate" or so?)
- should we have a voting threshold? that could for example be "3 users, and/or the author himself" lead to the review being moderated.
- does anyone need to be notified about anything by email here? The commenter, if their review is being removed (note: I see problems sending an email out in the commenter's language rather than the editor's, because of gettext)? The author?

Comments are much appreciated. CCing madhava, because he may have a suggestion on expected behavior for this feature.

Comment 1

[Andrew Williamson [:eviljeff]]

(In reply to comment #0)
> My thoughts:
> - we should add a link along the lines of "report this review" (possibly
> allowing to mark it "inaccurate" vs. "inappropriate" or so?)

Yeah, maybe even with a little (optional) comment box for the reason why.

> - should we have a voting threshold? that could for example be "3 users, and/or
> the author himself" lead to the review being moderated.

I'm not sure we'll get much abuse of the system here, as long as its restricted to logged in users.  We probably do need to track abusive/stupid commenters though now and have the ability to either disable their accounts or force-moderate their comments specifically. 

> - does anyone need to be notified about anything by email here? The commenter,
> if their review is being removed (note: I see problems sending an email out in
> the commenter's language rather than the editor's, because of gettext)? The
> author?

My first thought was 'everyone should be emailed' but at the moment we don't email anyone if a review is removed and it works okay-ish.  If we email the commenter then we're either going to have to write an explanation for each removal to send to them and/or prepare for users emailing the list asking why their comment was removed.  Probably best not to, or give us the option of not sending the email (a silent delete, like now).

Comment 2

[Seth Wagoner]

I agree with comment #1 - there should be a comment box for giving the reason the review is being flagged, and the commenters should not be emailed about rejected reviews or it should be optional. 

Comment 3

[Fred Wenzel [:wenzel]]

(from bug 428535 comment #12)
> Michel Gutierrez   2008-05-21 09:20:06 PDT
> As an extension developer, i find very dangerous to have auto-approved reviews.
> Back to the previous amo versions, when reviews were not moderated, you often
> got stupid and unfair comments, like "this extension is crap, check mine at
> xxx". Things improved a lot on amo 3 since all those mis-leading comments are
> filtered.
> 
> I agree that the review can be flagged, but it will take several days before
> the comment is removed. By that time, it will have been seen by hundred
> thousands people, affecting the number of installs if the review says "it's a
> spyware".
> 
> However, i understand the interest of removing workload from the reviewers.
> 
> Could we do something like this:
> 
> • someone writes a review, it is immediately displayed
> • the addon author flags the review, it is immediately removed from public
> view
> • a reviewer may then decide to re-enable the review (if it's a really
> spyware, the world must know)
> 

Comment 4

[Fred Wenzel [:wenzel]]

For 3.4.3, we'll just add the "report a review" and we'll discuss and design for upcoming releases.

Comment 5

[Fred Wenzel [:wenzel]]

Attachment: Review flagging

This patch allows logged-in users to flag reviews for editor approval. It works ajaxy but also when JS is disabled.

What's still missing (but has to go in at the same time, I'll make another patch): Reviews need to show up publicly despite their being marked for editor review. Otherwise clicking the new link will make the comment vanish until an editor touches it.

Comment 6

[Justin Scott [:fligtar]]

Comment on attachment 322154 [details] [diff] [review]
Review flagging

Looks good. A few nits:

>Index: controllers/reviews_controller.php
>===================================================================
>+            $this->publish('msg', (_('review_flag_success')!='review_flag_success'?
>+                _('review_flag_success'):'Thanks, this review was flagged for editor approval.'));

The comma should be a semicolon ("Thanks; this review..."). Perhaps "was" should be changed to "has been" so it doesn't sound like it was already flagged before the user just did it?

>Index: views/reviews/display.thtml
>===================================================================
>+<?php echo $javascript->link('reviews')."\n"; ?>

You can publish $jsAdd from the controller to include JavaScript files in the <head>.

Comment 7

[Fred Wenzel [:wenzel]]

(In reply to comment #6)
> The comma should be a semicolon ("Thanks; this review..."). Perhaps "was"
> should be changed to "has been" so it doesn't sound like it was already flagged before the user just did it?

Thanks, I'll change the wording.

> >Index: views/reviews/display.thtml
> >===================================================================
> >+<?php echo $javascript->link('reviews')."\n"; ?>
> 
> You can publish $jsAdd from the controller to include JavaScript files in the
> <head>.

Yeah I thought I should put it there per http://developer.yahoo.com/performance/rules.html#js_bottom -- something rdoherty suggested. Do you prefer me to put it into the <head> now and we'll do a bunch of JS performance enhancements at a later time?

Comment 8

[Justin Scott [:fligtar]]

Up to you.

Comment 9

[Fred Wenzel [:wenzel]]

Attachment: Review flagging, rev. 2

Sorry you need to re-review my patch, as I needed to replace the action by a POST request.

While at it, I used cpollett's ___() fallback function too.

Comment 10

[Justin Scott [:fligtar]]

Comment on attachment 322401 [details] [diff] [review]
Review flagging, rev. 2

When JS is disabled and I flag a review, the review is flagged and disappears from the list. When I have JS enabled and it flags the review via AJAX, when I refresh the page the review is still there. I don't think the AJAX is flagging correctly.

Comment 11

[Fred Wenzel [:wenzel]]

Attachment: rev. 3: = rev. 2, plus showing flagged reviews publicly

Actually, flagging a review without removing it from the page immediately until an editor chooses to delete it is expected behavior. The new patch does this consistently. Revision 2 may have done that in some places but not others, sorry about that.

I re-checked the (new) patch and the ajax as well as non-ajax actions both result in the review not vanishing from the reviews page on reload, however, they show up as the new last items in the editor review queue.

Can you check for one review if this works the same for you? Do you get a positive feedback message displayed in both cases?

Comment 12

[Justin Scott [:fligtar]]

I think that's a patch for a different bug.

Comment 13

[Fred Wenzel [:wenzel]]

Attachment: argh, now this is the right patch.

ouch, of course you are right, thanks. This one should be the right one now though.

Comment 14

[Justin Scott [:fligtar]]

Comment on attachment 322740 [details] [diff] [review]
argh, now this is the right patch.

Looks good. Thanks.

Comment 15

[Fred Wenzel [:wenzel]]

Cool. It's in r14104.

Comment 16

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED with JavaScript both enabled and disabled -- I did notice that our old friend Mr. Review Count Issue is back, but I believe that to be an auto-approve-by-default bug unrelated to this one; I'll investigate and file.

Please also note that bug 435156 covers improvements to what we've implemented here.

Comment 17

[Fred Wenzel [:wenzel]]

(In reply to comment #16)
> Verified FIXED with JavaScript both enabled and disabled -- I did notice that
> our old friend Mr. Review Count Issue is back, but I believe that to be an
> auto-approve-by-default bug unrelated to this one; I'll investigate and file.

btw, Mr. Review Count Issue is bug 436810.

Comment 18

[Michael Kraft [:morac]]

Has this been released?  I can't tell if 3.4.3 has been released or not since the version number isn't listed anywhere on the web site I can find, but since the status is verified fixed I'd assume it is.  I don't see a way to flag for review on my addon page at https://addons.mozilla.org/en-US/firefox/addon/1264

I'd like to flag the following review for obvious reasons (what's sad is that it works fine in 3.0):

    Not compatible for 3.0, this guy is an Idiot
    When is this F***ing idiot going to make it compatible for 3.0?

Comment 19

[Basil Hashem [:baz]]

Michael, actually we had intended to push AMO 3.4.3 last week but has to postpone it to this week due to a last minute issue (http://blog.mozilla.com/webdev/2008/06/06/amo-343-delayed-until-june-12th/). In the meantime, I've deleted this bad review. We don't accept name calling and foul language in reviews. It will take a few hours for the cache to expire and have it be gone.