Is your feature request related to a problem? Please describe.
It would be nice if our user profiles could include pronouns.
Describe the solution you'd like
Text field, done in the same way as location or whatever.
Describe alternatives you've considered
Adding it into my bio sorta works but then it shows up everywhere, and having it as structured data would be nice.
Additional context
Having freeform informational fields might be a more general option as well; this works pretty well on Mastodon.
Thanks for the request! We agree that there should be a better way to display pronouns, and like your suggestion on going the mastodon route. For anyone who wants to tackle this issue, how about adding two fields that allow key values?
Thoughts on how this would be displayed on the profile are also welcome but please provide a mockup before you dive into it!
I'd like to pick this up. Could you elaborate on what you mean by adding two fields? Shouldn't simple string type field suffice for this?
@FarazPatankar Awesome. So instead of having a specific pronoun field, we'd like to give people two fields on their profile to put whatever they want. For example:
Key1: Value1 (ie. Pronoun: She/Her/Hers)
Key2: Value2 (ie. Fav programming movie: title)
In this situation, the user would decide that for field1, they want to share their pronoun. In field2, they can share something else, which could be _anything_ such as age, spoken languages, etc. This would essentially be space for users to add two additional elements of their identity that they would like to share.
Oh, that sounds really cool. Do you have any thoughts on how you'd like for it to be implemented?
Not sure if you missed this, @jessleenyc. I'd still like to do this but I am not sure what the best/performant approach would be. Should I just add a json field to the user model?
Also, I think it'd be better if we gave the users a list of options that they could choose from for these fields. We can keep that list as broad as we'd like.
Let me know what you think.
@FarazPatankar Let's explicitly cap this at a few new fields, instead of wholly abstract json
Let's do: optional_field_key_1, optional_field_value_1, optional_field_key_2, optional_field_value_2, optional_field_key_3, optional_field_value_3.
Let's cap this at exactly three. If we change our minds in the future we can migrate later. Let's add the fields, the appropriate constraints, and merge this. I think the part of adding the fields as options in settings should be a last mile feature built by the core team, to get the design right.
Hey @benhalpern,
Thanks for the quick response. I think what I am struggling to understand is how will we store these in the user model or the DB if the key names are dynamic? I suggested a JSON because that's how I have done it in the past.
There’s no reason for the storage keys to be dynamic. You have, say, six database columns, two for each key/value set.
In the future it can be generalized as a separate key/value store as a joined table but that’s overkill for the intended purpose for now.
After a re-read I realized where the ambiguity is in the description. They aren't really key-value storage, so much as label-description storage.
For example:
custom_label_1 => 'pronouns'
custom_description_1 => 'she/her or they/them'
custom_label_2 => 'favorite color'
custom_description_2 => 'purple'
custom_label_3 => 'best animal'
custom_description_3 => 'platypus'
Ah, I see. If we don't mind additional columns, how about we use a model instead?
Something like CustomField with a name and a description and then do a user has many custom fields? Or would that not be preferred because it'd be an additional query?
Hey @FarazPatankar, I love the approach of an additional model. It is the cleanest all in all.
CustomField is perfect. Implementing it with a has_many relationship would be good. All for this approach. We can cache this for display somehow, so the additional query would be fine.
Sounds good. I'll try to get a PR open soon. I am assuming it'll be a long-ish one as I am not necessarily well versed with what is expected when developing a full stack feature.
@FarazPatankar Do you still want to work on this? If not I don't mind taking it on as I think this would be a very useful feature!
@benhalpern @jessleenyc (or anyone else from the core team who can take a look):
I'm thinking of taking this on. I know there was discussion about adding a CustomField model, but unless you're envisioning allowing an arbitrary number of custom fields in the future I don't see how that would be cleaner/simpler than just adding 6 columns to the user table (optional_field_key_1, optional_field_value_1`, etc.).
Assuming we take the approach of just adding columns, I'm guessing there are no special validations needed on the User model for these fields (except for maybe a length limit?)
Edited to add: Maybe we should validate that if a given optional_field_key has a value then the corresponding optional_field_value should not be allowed to be blank?
@achasveachas I’m not sure I like the idea of having the custom fields in the User model as they might never be set and be empty on the model forever (or a long long time). I think it would be cleaner having a custom model for that and we could still limit the number of allowed custom tags via the rails validations.
On the other hand we could also set predefined fields on the User model like the preferred pronoun or language. This could be used to lend emphasis to specific tags that can be set.
Just wanted to jump in on this one as I saw @jessleenyc's and @nickytonline's pronouns included in their display names. Was curious if it was a new feature or not, and unfortunately couldn't find it.
Glad there's already an issue and definitely seems like something that should be built-in <3
Pinging this to see whether this is still alive. I’d love to see this feature implemented.
I’d offer myself up implementing this but I am not any good in the front end.
The feature is still ready for development. It just needs someone to take it on. It looks like @FarazPatankar was looking into it, but they appear to have abandoned working on it. @achasveachas did you work on this at all yet?
Didn't get a chance to, though would love to see it happen.
I'm busy for the rest of the week, but if someone wants to take it but isn't confident enough to take it on their own I would love to pair on this sometime next week maybe.
Hey y'all, I submitted a back-end implementation for addtional optional fields (including pronouns) in https://github.com/thepracticaldev/dev.to/pull/7246!
I don't feel comfortable enough to do the front-end, hope this gets implemented soon!
still interested in this :)
@ludwiczakpawel @lisasy, I'm guessing we don't really need any design for this for at least the form submission, but in regards to where it displays in the profile, I imagine both of you would like to provide feedback on that.
For example, here is my profile. I've added my pronouns as part of my name field, but this is what it currently looks like.

this would be my preferred implementation, in the sidebar:

Yeah, it definitely looks really good on the right.🔥
Love this!
On Mon, Jul 6, 2020 at 1:24 PM Nick Taylor notifications@github.com wrote:
Yeah, it definitely looks really good on the right.🔥
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/thepracticaldev/dev.to/issues/2365#issuecomment-654447398,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGHKEXS7SNA2NSYC7L4WBLR2IXJTANCNFSM4HFA3NOA
.
--
Lisa Sy
Lead Product Designer at DEV
Pronouns: she/her
@bnb @nickytonline I personally prefer the direction in @bnb mockup :)
@bnb @nickytonline I personally prefer the direction in @bnb mockup :)
Yeah, mine wasn’t really a mock-up. 😜 That’s what my actual profile looks like all the time. It’ll be nice to have it on the right.
Most helpful comment
this would be my preferred implementation, in the sidebar:
