Discussion:
[mb-devel] Feedback required for CritiqueBrainz's Moderation Interface
Shadab Zafar
2015-06-23 17:41:30 UTC
Permalink
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:

Loading Image...
Loading Image...

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
Roman Tsukanov
2015-06-25 22:15:06 UTC
Permalink
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
Post by Shadab Zafar
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.
http://i.imgur.com/Y9IWTP3.png
http://i.imgur.com/uGORND1.png
Read the revision. In case the review has been updated since the
report was created, another link titled 'Read Latest' will be shown.
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.)
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
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.
---
https://bitbucket.org/metabrainz/critiquebrainz/pull-request/275/cb-157-wip-moderation-interface/diff
Regards,
dufferZafar
_______________________________________________
MusicBrainz-devel mailing list
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
--
Roman
Shadab Zafar
2015-06-27 09:33:50 UTC
Permalink
Post by Roman Tsukanov
On screenshots that you linked there's a "Votes" column. Users can
vote on spam reports?

They are the votes on the associated revision, maybe I should change
the header to "Votes on revision".
Post by Roman Tsukanov
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.

I was thinking that maybe we could use this interface as a way to fix
issues like CB-150: http://tickets.musicbrainz.org/browse/CB-150

There was some discussion about it here:
http://chatlogs.musicbrainz.org/musicbrainz-devel/2015/2015-01/2015-01-13.html#T10-13-25-135366

So people could 'report' these reviews giving a reason like "F*** is
treated as markdown syntax", and then moderators could edit the review
to fix it.
Post by Roman Tsukanov
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.

I am working on a logging interface (which I guess will be visible to
everyone - not just the admins.)
Post by Roman Tsukanov
Overview of all spam reports seems to be missing.
Sorry but I don't get what you mean? This interface is the overview, isn't it?
Post by Roman Tsukanov
We also need a way to ban/delete users.
Considering that this action will only be taken when all the reviews
of a user are spam, I think we should just delete the user account
(which will also remove all the associated reviews.)

I'll add this action to the interface.
Roman Tsukanov
2015-06-28 01:57:20 UTC
Permalink
Post by Roman Tsukanov
Post by Roman Tsukanov
On screenshots that you linked there's a "Votes" column. Users can
vote on spam reports?
They are the votes on the associated revision, maybe I should change
the header to "Votes on revision".
I don't see vote counts being useful there. Moderator will have to go
and read reported revision anyway to make a decision. Maybe put votes
there?
Post by Roman Tsukanov
Post by Roman Tsukanov
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.
I was thinking that maybe we could use this interface as a way to fix
issues like CB-150: http://tickets.musicbrainz.org/browse/CB-150
Spam reports and issues in imported reviews are two completely
different problems. Second is a corner case which shouldn't affect
general moderation tasks. It's probably better to implement features
for spam report handling first.
Post by Roman Tsukanov
http://chatlogs.musicbrainz.org/musicbrainz-devel/2015/2015-01/2015-01-13.html#T10-13-25-135366
So people could 'report' these reviews giving a reason like "F*** is
treated as markdown syntax", and then moderators could edit the review
to fix it.
Then we need to rename "spam reports" into something else. Again, I
think it should be a separate task.
Post by Roman Tsukanov
Post by Roman Tsukanov
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.
I am working on a logging interface (which I guess will be visible to
everyone - not just the admins.)
Yeah, I think it's a good idea to make it transparent.
Post by Roman Tsukanov
Post by Roman Tsukanov
Overview of all spam reports seems to be missing.
Sorry but I don't get what you mean? This interface is the overview, isn't it?
Oh, I thought that these reports were only for one of the reviews.
Then it would be nice to see at least some information about reviews
in rows there.
Post by Roman Tsukanov
Post by Roman Tsukanov
We also need a way to ban/delete users.
Considering that this action will only be taken when all the reviews
of a user are spam, I think we should just delete the user account
(which will also remove all the associated reviews.)
I'm not sure if banning someone should mean that everything that this
user wrote needs to be deleted. What if some of their reviews are not
spam?

It would also be nice to make that action reversible. In case one of
the accounts is deleted by mistake or something else happens. Maybe
accounts should be blocked or archived instead? Though, these users
should still be able to delete their reviews or account completely,
even if they can't create new reviews, vote, etc. anymore.
--
Roman
Shadab Zafar
2015-06-29 16:03:15 UTC
Permalink
Post by Roman Tsukanov
Post by Shadab Zafar
Post by Roman Tsukanov
We also need a way to ban/delete users.
Considering that this action will only be taken when all the reviews
of a user are spam, I think we should just delete the user account
(which will also remove all the associated reviews.)
I'm not sure if banning someone should mean that everything that this
user wrote needs to be deleted. What if some of their reviews are not
spam?
It would also be nice to make that action reversible. In case one of
the accounts is deleted by mistake or something else happens. Maybe
accounts should be blocked or archived instead? Though, these users
should still be able to delete their reviews or account completely,
even if they can't create new reviews, vote, etc. anymore.
I thought of allowing admins to block a user account by adding a new
field 'user_type' (which could also be used for admin/moderators) but
there's already some user types defined in the constants file:
https://github.com/metabrainz/critiquebrainz/blob/master/critiquebrainz/data/constants.py#L13

I remember reading a comment from you somewhere that these user and
review classes just confuse people and should be removed, but I can't
seem to find a link for it.

Do you suggest that I should just drop these classes and make
necessary changes in the code before adding the user blocking thing?

---

dufferZafar
Roman Tsukanov
2015-06-29 20:12:55 UTC
Permalink
Post by Shadab Zafar
Post by Roman Tsukanov
Post by Shadab Zafar
Post by Roman Tsukanov
We also need a way to ban/delete users.
Considering that this action will only be taken when all the reviews
of a user are spam, I think we should just delete the user account
(which will also remove all the associated reviews.)
I'm not sure if banning someone should mean that everything that this
user wrote needs to be deleted. What if some of their reviews are not
spam?
It would also be nice to make that action reversible. In case one of
the accounts is deleted by mistake or something else happens. Maybe
accounts should be blocked or archived instead? Though, these users
should still be able to delete their reviews or account completely,
even if they can't create new reviews, vote, etc. anymore.
I thought of allowing admins to block a user account by adding a new
field 'user_type' (which could also be used for admin/moderators) but
https://github.com/metabrainz/critiquebrainz/blob/master/critiquebrainz/data/constants.py#L13
You can always modify the schema.
Post by Shadab Zafar
I remember reading a comment from you somewhere that these user and
review classes just confuse people and should be removed, but I can't
seem to find a link for it.
Do you suggest that I should just drop these classes and make
necessary changes in the code before adding the user blocking thing?
Do these two things depend on each other? It's probably better to keep
them separate.
--
Roman
Loading...