Re: GSoC 2015 - Interface Improvements to CritiqueBrainz

>  > To properly handle spam reports we might need some kind of user type
>  > field that would indicate what user is allowed to do (post reviews,
>  > decide what to do with spam reports, edit other reviews). For example,
>  > we might want to deny some user access to review creation when they
>  > post too much spam.
>
> We can have a user `status` field which'll store what the user can do. It
> could have values like 'Normal', 'Moderator', 'Suspended'. But who will
> decide
> which user has moderation/admin powers?

Someone will. I don't think you should worry about that right now.

> In the docs, we'll have to make sure the status is not confused with the
> UserType field (which is based on karma.)

I actually don't like this user and review type system [1]. It seems
useless right now. Maybe we should think about removing it or
replacing with something else. This definitely needs some discussion.

>  > This section doesn't have to be limited to handling spam reports.
>  > There might be some other useful functionality in this "moderation
>  > interface". For example, fixing imported reviews (see CB-150).
>
> I am not sure I get how the interface will be used to fix those reviews.
>
> Will the reviews be listed there and the moderator will do some sort of bulk
> operation on all the imported reviews?

Just some simple way to fix (imported) reviews for privileged users. I
don't know what kind of bulk operation you have in mind.

>  > Another thing that I think is necessary there is logging.
>  > We need to know what actions are taking place in this interface
>  > and who makes them.
>
> Logging will be a nice addition. Should we log everything that's
> happening on
> the site (review creation, revision updates, spam reports, actions by
> moderators) or just the stuff coming from the moderation interface?

I'm talking about moderation interface. We already have timestamps on
each revision and spam report.

> We might also need some log filtering features so that a user can view
> events
> specific to their reviews.
>
> ---
>
>  > Revisions and UI that will be implemented there might be useful for
>  > integration with moderation and editing by admins.
>
> So an admin will be able to revert any review to any revision?

Revisions are public. They should be used for keeping track of any
content changes (by admins or authors). Author should be able to
revert back to any revision.

> With the current schema, I don't think we'll ever be able to fix CB-36 (the
> way we want to). Will changing the schema to store an artist's id along with
> the review make sense?

I don't think keeping this kind of information in CritiqueBrainz is a
good idea. References to artists can change.

>  > You could outline a schedule to show how much time you think it would
>  > take to fix things that you mentioned and see what else you will have
>  > time for.
>
> For my schedule, I was thinking of adding the entities related stuff
> first, as
> it is a bit big in comparison to other things and will likely have some bugs
> once it is finished, then I could focus on adding the rest of the things and
> fixing the bugs.

I don't have a lot of system design experience, but it seems like
adding more weight before fixing existing problems seems like a bad
strategy. See https://en.wikipedia.org/wiki/Technical_debt.

> I prefer artists from my country. Perhaps we could have a user
> preference for
> country and favour displaying those reviews. But this can't be done with our
> current schema (reviews don't have associated country.)

Might be better to extend existing existing review browsing feature
[2] by adding filters there.


[1] https://github.com/metabrainz/critiquebrainz/blob/master/critiquebrainz/data/constants.py
[2] https://critiquebrainz.org/review/

-- 
Roman