Add AI preference options #1911
Conversation
| if request.user.profile.num_sounds == 0: | ||
| self.fields.pop('ai_sound_usage_preference') |
There was a problem hiding this comment.
does this mean that the process for a user to change their preference means that they first need to upload a sound and then go back to their profile? Can we make it clearer somehow?
There was a problem hiding this comment.
So far yes, but maybe we could think of redirecting users to the setting. Well, maybe not redirecting because I don't like that, but we could add a banner in the "manage sounds" page for users that have sounds and have no preference set explicitly. In this way, users that already have sounds will see the banner, and also right after describing a sound, when redirected to the manage sounds page, the banner will appear as well. Also I could move the AI preference to a new tab in the account settings page for more clarity and discoverability.
There was a problem hiding this comment.
Aaaaand we could email uploaders about that. It will be ~38k emails, so should be doable...
There was a problem hiding this comment.
that's a good place to also verify that our email bounce code is working and use it to verify uploader accounts!
| # If no preference is set, return the default one | ||
| return AIPreference.DEFAULT_AI_PREFERENCE | ||
|
|
||
| def set_ai_preference(self, preference_value): |
There was a problem hiding this comment.
isn't this just create_or_update?
I don't think the .update is correct, you need to filter on the user first
There was a problem hiding this comment.
Hmm you might be right, although I think it is strange that I did not test that. Anyway, I still need to add unit tests so I'll make sure this is covered and consider the reimplementation. Thanks!
| AI_PREFERENCE_CHOICES = ( | ||
| ("fr", "My sounds are used following Freesound's recommendations for interpreting Creative Commons licenses in a generative AI training context"), |
There was a problem hiding this comment.
a new way that we can do this is models.TextChoices: https://docs.djangoproject.com/en/5.2/ref/models/fields/#enumeration-types
Let's use descriptive names too, instead of these small 1-2 letter codes
There was a problem hiding this comment.
Thanks for the suggestion, I'll look into that! The short cryptic names are because of DB char column length, but maybe the new field type already does some "translation", or maybe my assumption that limiting the chars would be more optimal is just not valid as PG will use some enum internally instead.
There was a problem hiding this comment.
note that TextChoices isn't a new field type, it's just a data type that makes it a bit easier to handle choices for a CharField, much more similar to a python enum.
Additionally, I was suggesting to not have a short column. In postgres there's no difference between a length 2, length 100, or unlimited length text field. Especially in our case where we only ever read the value. Let's make things easier on ourselves and make it readable when it's in the database.
There is a library which allows us to use a postgres enum in this column, which we could use if you want. I'm not too worried about it: https://github.com/django-commons/django-enum
Description
Adds the "AI preference" option in the user profile so users can express their AI preferences. This is only displayed for users that have sounds. That preference can also be included as a sound serializer field in the API, and as a user serializer field in the API.
Also adds some help text and functions in the sound describe form to add GenAI tag for sounds generated with generative AI.
Deployment steps:
Migrate DB. Also, we'll need to update FAQ section with the meaning of the AI preference options, and API docs.