Re: Feedback required for CritiqueBrainz's Moderation Interface

Roman Tsukanov <[email protected]> Fri, 26 Jun 2015 07:15:06 +0900
Newsgroups gmane.comp.audio.musicbrainz.devel
Message-ID <CAJ6GbdKi7tq72Gubne2denD=RXDSc6s8mD+n+Gc-ztt-Db8dyA@mail.gmail.com>
On screenshots that you linked there's a "Votes" column. Users can
vote on spam reports?

Don't know why moderators would need to edit reviews. I think only
author should be able to do that. Their name is associated with review
and it's not a wiki page.

Function for deleting spam reports seems unnecessary. And I think that
some kind of logging system for admin actions should be a part of this
interface. Overview of all spam reports seems to be missing.

We also need a way to ban/delete users. See my comment in pull request [1].

[1] - https://bitbucket.org/metabrainz/critiquebrainz/pull-request/275/cb-157-wip-moderation-interface/diff#comment-7808477


On Wed, Jun 24, 2015 at 2:41 AM, Shadab Zafar <[email protected]> wrote:
> I've done some work on a Moderation interface for CritiqueBrainz
> whereby admins will be able to handle the spam reports that are
> generated.
>
> I'm not sure what features would make most sense for such an
> interface, so I think asking people who will actually be using it
> would be the best way forward.
>
> This is how the view looks currently:
>
> http://i.imgur.com/Y9IWTP3.png
> http://i.imgur.com/uGORND1.png
>
> The split dropdown lists the actions a moderator can take on a review:
>
> Read:
>
> Read the revision. In case the review has been updated since the
> report was created, another link titled 'Read Latest' will be shown.
>
> Edit:
>
> Edit the review. The way I've implemented this functionality
> currently, a new revision is created, but we don't track that it was
> created by an admin (and not by the review's author.)
>
> I personally feel that we should add a new field (user_id) for each
> revision which will keep track of who created it. It can be null if
> the revision author is same as the review author (which will be the
> case most of the time.)
>
> Delete:
>
> Deleting a review is straightforward.
>
> In case we don't really want to delete a review (I'm not sure why we
> might want to do this) - we could add a 'hidden' field. A review that
> is marked hidden will only be visible to the author and the
> moderators, but will 404 for anyone else.
>
> ---
>
> What would happen to a report when an appropriate action has been
> taken on the associated review?
>
> We could just delete the report, or we could add a 'status' field
> which could have values like 'resolved', 'wontfix' etc. (Am I
> overthinking this?)
>
> I personally feel adding a 'status' field would be worth it, and will
> leave more oprtions for the future.
>
> ---
>
> I also toyed with adding bulk editing capabilities, so you could just
> select some reviews and mark them all as resolved. I used the
> bootstrap-table plugin for it:
> http://bootstrap-table.wenzhixin.net.cn/ which greatly simplified
> sorting and similar table related stuff.
>
> But, as I said before, I'm not sure if adding features like these
> would actually be useful.
>
> ---
>
> In case you're interested in the code, here is the pull:
> https://bitbucket.org/metabrainz/critiquebrainz/pull-request/275/cb-157-wip-moderation-interface/diff
>
> Regards,
>
> dufferZafar
>
> _______________________________________________
> MusicBrainz-devel mailing list
> [email protected]
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel



-- 
Roman