Feedback required for CritiqueBrainz's Moderation Interface

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Feedback required for CritiqueBrainz's Moderation Interface

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.

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
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feedback required for CritiqueBrainz's Moderation Interface

Roman Tsukanov
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 <[hidden email]> 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
> [hidden email]
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel



--
Roman

_______________________________________________
MusicBrainz-devel mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feedback required for CritiqueBrainz's Moderation Interface

Shadab Zafar
On 6/26/15, Roman Tsukanov <[hidden email]> wrote:

> 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".

> 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.

> 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.)

> 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?

> 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.

_______________________________________________
MusicBrainz-devel mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feedback required for CritiqueBrainz's Moderation Interface

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?

>> 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.

> 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.

Then we need to rename "spam reports" into something else. Again, I
think it should be a separate task.

>> 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.

>> 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.

>> 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

_______________________________________________
MusicBrainz-devel mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feedback required for CritiqueBrainz's Moderation Interface

Shadab Zafar
On 6/28/15, Roman Tsukanov <[hidden email]> wrote:

>>> 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

_______________________________________________
MusicBrainz-devel mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Feedback required for CritiqueBrainz's Moderation Interface

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

You can always modify the schema.

> 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

_______________________________________________
MusicBrainz-devel mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
Loading...