Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow sound moderators to ignore users when assigning user's pending sounds #1776

Open
qubodup opened this issue Jun 8, 2024 · 0 comments
Open

Comments

@qubodup
Copy link

qubodup commented Jun 8, 2024

Moderating Freesound sounds can be stressful. Volunteering eventually leads to encountering distress-causing sounds (contributes to burnout). When you defer problem sounds, you still see them in the assignment queue, which reminds you of the problems and can make you feel guilty (contributes to burnout) for letting other moderators deal with the hard cases. Also you have to use your own brain to remember negative information (contributes to burnout) about which users/avatars tend to problem sounds when a computer could easily do it for you. The consequent inability to use "Assign all" slows down moderation.

Freesound moderation burnout mindmap

One of the reasons I had a huge hiatus from Freesound moderation is the inability to escape content that was stressful to moderate.

Distress can mean:

  • content that is viscerally unpleasant to the moderator due to content (disgusting content, music grey area), creation method (ai, legal grey area) or quality (constant low quality audio/metadata)
  • content of users moderation of which requires communication but the communication of this particular moderator and user pair is highly stressful (uploader unwillingness to improve metadata, uploader ignoring deferred improvement requests)

Solution:

  • Implement a filter based on user in moderation assignment. Store "ignored" users

Benefit:

  • Moderators who are compatible with "out of sight, out of mind" thinking can experience relief (I confirm this works very well for me) and burnout can be delayed/prevented

Drawbacks:

  • Potentially other moderators (incompatible with "out of sight, out of mind") will be bothered by any pending sounds, even if filtered out and feel guilty/responsible for these sounds still pending. These hypothetical moderators can then experience even more stress which perhaps was more evenly distributed before.
  • Admins might end up having to deal with more stressful content contributing to their burnout, taking away from their time available for Freesound.
  • Some sounds might end up never moderated, which seems like an acceptable solution. Handling a large quantity of such sounds is something to consider down the line if implemented.
  • The suggestion to filter per-user is based on years of Freesound volunteer moderation experience and I stand by it. However, potentially one user might change upload content/behavior which might then get missed. This can be counteracted by making it easy to check on ignored pending sounds (quick client side filtering instead of server-side as seen in userscript below).

Implementation example:
Firefox/Chrome userscript for Greasemonkey/Tampermonkey: https://github.com/qubodup/freesound-mod_user_filter/ cc0 code. Use video, install guide, feature list present in Readme. Warning: uses jQuery.

Screenshot:

Freesound_-Moderation-Assign_sounds-_Google_Ch_24-06-08_13-57-34_1xu
[anonymized names/avatars]

Notes

  • In my testing, I stopped using "favorite" after a few days. It is minimally useful to identify highly active users over a course of multiple days. This adds a little bit of psychological motivation boost ("ah, I see some green, this is very likely to be at least partially a pleasant experience" as opposed to not knowing what to expect unless inspecting users' pending sounds individually) but this is rare.
  • The "assign all" button must be protected by a JS confirm() box, as it assigns invisible users too.
  • Implementation of an assign_users() method / url / api call might be required, which accepts a list of user IDs although my ugly iframe solutions works quite well for now.
  • pressing "ignore" should not hide the user instantly, as double-clicks happen. The user should be marked as hidden. A js refresh button could be added. Behavior for assigning currently visible users could have a warning or require a refresh view action first or be replaced with a 'refresh list' button if not yet reflected changes are in the list.
  • The issue is solved for me personally through the userscript. This adds imbalance: moderators who are unaware or do not want or cannot use extensions/userscripts are at a potential disadvantage.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant