Comment 4 for bug 675504

On Thu, Nov 25, 2010 at 5:23 PM, Matthew Paul Thomas <email address hidden> wrote:
> Does that mean we can have both flagging, and optional pre-publication
> moderation? I think we might want to start out with pre-publication
> moderation turned on, and then turn it off in a month or two if (a) the
> volume gets too much for manual moderation or (b) we're confident we
> have automatic filters for as much bad stuff as we can. And then turn it
> back on temporarily if anyone ever tries to flood the review service.

Yep - indeed. Gatekeeper has simple setting to enable that. That is,
it would require an update to the configuration branch (it would be a
nice improvement to gatekeeper if it was an option in the admin
web-interface).

>
> As for the original question about Review.hide, with a sufficiently
> large number of users, people will flag reviews for all kinds of
> spurious reasons, maybe even by accident. It would then be the job of a
> moderator to look not at every flagged review, but at those reviews that
> have been flagged the most times.

Yep, so with the current implementation (in the above branch), I've
ensured that:

1) If the review has not been manually approved, then flagging will
move it to the pending state (ie. hiding it awaiting moderation).
2) If the review *has* already been manually approved, then flagging
will not change it's state, but it will be flagged for moderation
(perhaps a different queue - up to us).

The current implementation of gatekeeper won't allow us to provide the
flagged reviews that have been flagged most often (although looking at
a review moderation, you'll be able to see all the flag-comments).
Enabling records for each flag event is an an improvement which we
could contribute back upstream (or if necessary, fork and improve).
I'll start some discussion there with the author.