github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-15 20:52:52 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

[Feature Request] Optional pronoun field in profile #6522

New Issue
Open
opened 2025-11-02 06:58:28 -06:00 by GiteaMirror · 6 comments
GiteaMirror commented 2025-11-02 06:58:28 -06:00
Owner
Copy Link

Originally created by @alch-emi on GitHub (Dec 15, 2020).

Hi all!

Summary

I'm proposing to add a new field to the user biography, specifically for pronouns. Like the website, location, and bio fields, the user would not be required to use this field, and if they elected to leave it out, the field would not be displayed. If the field is set, it would be displayed alongside a small icon, such as octicons-comment-discussion. Input to the field would be 64 characters of free text.

Demo

Motivation

The process of building software, especially in a community-focused open source environment, makes inevitable the need to refer to other contributors in the third person. This creates a problem, as English, and many other languages, have multiple third-person pronouns to refer to users. On the internet, there's often no easy way to tell which is appropriate.

While using they/them pronouns (as in, “Alex mentioned in their review that…”) for every user of the site works, it might not be the ideal solution, especially as users become more integrated into projects, and people still don't know how to refer to them.

Considerations

  • If a user does not want to specify their pronouns then this change would not affect them. As with the other profile fields, a pronoun field could be hidden when empty, meaning their bio (and that of anyone else who hasn't engaged with the feature) will look exactly the same
  • If a sysadmin is working under a size constraint or a user is connecting on a low bandwidth connection this should not increase the size of the application nor payload considerably. The icon proposed is already included in the octicons icon set currently in use by Gitea, and the example depicted in the image should add only 226 bytes, including whitespace and newlines.
  • If a user who uses a non-English language or a user who uses non-standard pronouns needs to use Gitea, they may specify pronouns appropriate to their language, or enter any non-standard or case-specific pronouns, since the input field is agnostic to content beyond accepting no more than 64 characters. Even very specific, multi-language pronouns could easily be specified within this space (“DE: er/ihn, EN: he/him or they/them” is only 35 characters [Note: I don't actually know German, apologies if this is a misrepresentation of how people present their pronouns in German]). A user whose language does not include multiple personal pronouns and does not speak a language that does my simply leave the field blank.
  • If an unprivileged but registered user is looking to abuse the system this addition should not grant them any leverage that they didn't already have. The amount of text that may be entered is small (smaller, in fact, than other fields in the bio), and should not expose any attack vectors not already available in the other fields. The implementation should seek to apply the same safety checks as are used in these fields to ensure this.
  • If a user seeks to use the field to communicate some other information then this change fully enables them to do so. Although the UI encourages the use of the field to communicate pronouns, any other 64 characters that may be accompanied by the octicons-comment-discussion is entirely possible. This does not undermine the feature motivation, as users who do not want to share their pronouns will always be welcome to, and granting users more freedom will not hurt.

Other Discussions & Notes

I was unable to find any other issues or pull requests discussing the addition of a pronoun field, nor any other additional or custom field. The closest related issue I could find was #4339, calling for the addition of a user biography. This issue has since been implemented and closed. The only criticism of the request was that it may be out of scope. To address this concern in relation to this request, I do not believe that this should be out of scope for the project. I would suggest Gitea is just as much about discussion and collaboratively building code as it is about the code itself, and that the knowledge of how to correctly refer to your fellow collaborators is just as important as knowing things such as their location or website, if not more so.

I'm willing to try to implement this feature myself, but I'm opening an issue to get some advice and input from the community, and to respect the Gitea contribution workflow. I'd be happy to address any concerns or accept constructive criticism, such that this thread might be a better resource either to me or a future developer

Originally created by @alch-emi on GitHub (Dec 15, 2020). Hi all! # Summary I'm proposing to add a new field to the user biography, specifically for pronouns. Like the website, location, and bio fields, the user would not be required to use this field, and if they elected to leave it out, the field would not be displayed. If the field is set, it would be displayed alongside a small icon, such as ![octicons-comment-discussion]. Input to the field would be 64 characters of free text. ![Demo](https://user-images.githubusercontent.com/38897201/102126815-992e8780-3e19-11eb-95eb-71e358d67b9e.png) # Motivation The process of building software, especially in a community-focused open source environment, makes inevitable the need to refer to other contributors in the third person. This creates a problem, as English, and many other languages, have multiple third-person pronouns to refer to users. On the internet, there's often no easy way to tell which is appropriate. While using they/them pronouns (as in, “Alex mentioned in **their** review that…”) for every user of the site works, it might not be the ideal solution, especially as users become more integrated into projects, and people *still* don't know how to refer to them. # Considerations * If **a user does not want to specify their pronouns** then this change would not affect them. As with the other profile fields, a pronoun field could be hidden when empty, meaning their bio (and that of anyone else who hasn't engaged with the feature) will look exactly the same * If **a sysadmin is working under a size constraint** or **a user is connecting on a low bandwidth connection** this should not increase the size of the application nor payload considerably. The icon proposed is already included in the octicons icon set currently in use by Gitea, and the example depicted in the image should add only 226 bytes, including whitespace and newlines. * If **a user who uses a non-English language** or **a user who uses non-standard pronouns** needs to use Gitea, they may specify pronouns appropriate to their language, or enter any non-standard or case-specific pronouns, since the input field is agnostic to content beyond accepting no more than 64 characters. Even very specific, multi-language pronouns could easily be specified within this space (“DE: er/ihn, EN: he/him or they/them” is only 35 characters [*Note: I don't actually know German, apologies if this is a misrepresentation of how people present their pronouns in German*]). **A user whose language does not include multiple personal pronouns** and does not speak a language that does my simply leave the field blank. * If **an unprivileged but registered user is looking to abuse the system** this addition should not grant them any leverage that they didn't already have. The amount of text that may be entered is small (smaller, in fact, than other fields in the bio), and should not expose any attack vectors not already available in the other fields. The implementation should seek to apply the same safety checks as are used in these fields to ensure this. * If **a user seeks to use the field to communicate some other information** then this change fully enables them to do so. Although the UI encourages the use of the field to communicate pronouns, any other 64 characters that may be accompanied by the ![octicons-comment-discussion] is entirely possible. This does not undermine the feature motivation, as users who do not want to share their pronouns will always be welcome to, and granting users more freedom will not hurt. # Other Discussions & Notes I was unable to find any other issues or pull requests discussing the addition of a pronoun field, nor any other additional or custom field. The closest related issue I could find was #4339, calling for the addition of a user biography. This issue has since been implemented and closed. The only criticism of the request was that it may be out of scope. To address this concern in relation to this request, I do not believe that this should be out of scope for the project. I would suggest Gitea is just as much about discussion and collaboratively building code as it is about the code itself, and that the knowledge of how to correctly refer to your fellow collaborators is just as important as knowing things such as their location or website, if not more so. I'm willing to try to implement this feature myself, but I'm opening an issue to get some advice and input from the community, and to respect the Gitea contribution workflow. I'd be happy to address any concerns or accept constructive criticism, such that this thread might be a better resource either to me or a future developer [octicons-comment-discussion]: https://user-images.githubusercontent.com/38897201/102125736-21139200-3e18-11eb-87c6-1aee659fdf5a.png
GiteaMirror added the type/proposal label 2025-11-02 06:58:28 -06:00
GiteaMirror commented 2025-11-02 06:58:29 -06:00
Author
Owner
Copy Link

@jolheiser commented on GitHub (Dec 15, 2020):

It seems like a user could just put this in their bio, no?

@jolheiser commented on GitHub (Dec 15, 2020): It seems like a user could just put this in their bio, no?
GiteaMirror commented 2025-11-02 06:58:29 -06:00
Author
Owner
Copy Link

@techknowlogick commented on GitHub (Dec 15, 2020):

The bio field is free form to cover this case, just like you are achieving in you GitHub profile currently.

@techknowlogick commented on GitHub (Dec 15, 2020): The bio field is free form to cover this case, just like you are achieving in you GitHub profile currently.
GiteaMirror commented 2025-11-02 06:58:30 -06:00
Author
Owner
Copy Link

@alch-emi commented on GitHub (Dec 15, 2020):

Respectfully, I'd like to appeal the decision to close this. While the bio field absolutely works to convey pronouns, and I'm happy that it's an option, I see it as a stopgap at best.

While people can use the bio field to convey pronouns, people typically don't use the bio field. I think adding a specific pronoun field would encourage users to share their pronouns, which many people would find beneficial.

Additionally, if a user chooses to use the pronoun field to share their pronouns, they are forced to either cram their bio into the space after their pronouns, or cram their pronouns into the space after their bio.

I do recognize that for most users, this will be a small change, but I do think it will be a net positive for many users. I'd argue that UX is often the summation of many small things just like this.

I think that this would provide a lot of benefit to a lot of people, with next to no cost for most other users. I am also more than willing to do the devwork if that itself is a concern.

I'd at least like to request that the issue be kept open so that we might discuss it.

@alch-emi commented on GitHub (Dec 15, 2020): Respectfully, I'd like to appeal the decision to close this. While the bio field absolutely works to convey pronouns, and I'm happy that it's an option, I see it as a stopgap at best. While people _can_ use the bio field to convey pronouns, people typically _don't_ use the bio field. I think adding a specific pronoun field would encourage users to share their pronouns, which many people would find beneficial. Additionally, if a user chooses to use the pronoun field to share their pronouns, they are forced to either cram their bio into the space after their pronouns, or cram their pronouns into the space after their bio. I do recognize that for most users, this will be a small change, but I do think it will be a net positive for many users. I'd argue that UX is often the summation of many small things just like this. I think that this would provide a lot of benefit to a lot of people, with next to no cost for most other users. I am also more than willing to do the devwork if that itself is a concern. I'd at least like to request that the issue be kept open so that we might discuss it.
GiteaMirror commented 2025-11-02 06:58:30 -06:00
Author
Owner
Copy Link

@techknowlogick commented on GitHub (Dec 15, 2020):

This is exactly the purpose of the bio field to provide biographical information on who the user is. If the issue is that no one uses something, that's not a vote of confidence for adding yet another field that won't be used. If the issue is that users need to cram in information into the bio field, then the field should be expanded to accommodate this. Unfortunately, UX can also be negatively impacted by having too many fields so adding new ones we need to be careful.

@techknowlogick commented on GitHub (Dec 15, 2020): This is exactly the purpose of the bio field to provide biographical information on who the user is. If the issue is that no one uses something, that's not a vote of confidence for adding yet another field that won't be used. If the issue is that users need to cram in information into the bio field, then the field should be expanded to accommodate this. Unfortunately, UX can also be negatively impacted by having too many fields so adding new ones we need to be careful.
GiteaMirror commented 2025-11-02 06:58:30 -06:00
Author
Owner
Copy Link

@alch-emi commented on GitHub (Dec 15, 2020):

Thank you for the response. While I do see where you're coming from, I believe you've overlooked some key things.

If the issue is that no one uses something, that's not a vote of confidence for adding yet another field that won't be used.

I don't believe that this is true, nor that this reflects the current attitude of Gitea towards other fields. As I interpret it, you're suggesting to justify a feature, if another feature can be used to that end, then users are using that feature to that end. In this case, this feature is invalid because the bio field can be used to that end, but only a few users are using it that way. If this is the case, I'm happy to open up a new issue to remove the location field. This field can easily be replaced by the bio field, though I doubt too many users would immediately use it for that.

If the issue is that users need to cram in information into the bio field, then the field should be expanded to accommodate this.

I think I may have used poor wording here. I meant to refer to visual or cognitive cramming of one's bio. For example, the following bio does not run up against the space limit, but is very much crammed:

[he/him] An entrepreneuring FOSS developer (22 y/o) [Student, CalTech]

In this sense, cramming is solved not by extending the field itself, but by allowing users to present their information in a more ordered fashion, in this case by adding more fields. I'm not arguing that we should add an age field, a job field, and a hair color field, but add a select few specialized fields for very important information, as has been done with Location.

Unfortunately, UX can also be negatively impacted by having too many fields so adding new ones we need to be careful.

I wholeheartedly agree, and Gitea's exactly-as-much-as-it-needs-to-be UI is the biggest reason I love it over GitLab and GitHub. I've been working in Gitea via a friend's instance for a while, fell in love with the UX enough that I've started the process of working on my own instance, and will be migrating my projects over soon. I wholeheartedly understand the need to avoid cluttering the UI. However, I think that this change, between the fact that it only actually shows up when filled, but provides a very important service, falls squarely on the "worthwhile" end of this spectrum.

@alch-emi commented on GitHub (Dec 15, 2020): Thank you for the response. While I do see where you're coming from, I believe you've overlooked some key things. > If the issue is that no one uses something, that's not a vote of confidence for adding yet another field that won't be used. I don't believe that this is true, nor that this reflects the current attitude of Gitea towards other fields. As I interpret it, you're suggesting to justify a feature, if another feature can be used to that end, then users *are* using that feature to that end. In this case, this feature is invalid because the bio field can be used to that end, but only a few users are using it that way. If this is the case, I'm happy to open up a new issue to remove the location field. This field can easily be replaced by the bio field, though I doubt too many users would immediately use it for that. > If the issue is that users need to cram in information into the bio field, then the field should be expanded to accommodate this. I think I may have used poor wording here. I meant to refer to visual or cognitive cramming of one's bio. For example, the following bio does not run up against the space limit, but is very much crammed: `[he/him] An entrepreneuring FOSS developer (22 y/o) [Student, CalTech]` In this sense, cramming is solved not by extending the field itself, but by allowing users to present their information in a more ordered fashion, in this case by adding more fields. I'm not arguing that we should add an age field, a job field, and a hair color field, but add a select few specialized fields for very important information, as has been done with Location. > Unfortunately, UX can also be negatively impacted by having too many fields so adding new ones we need to be careful. I wholeheartedly agree, and Gitea's exactly-as-much-as-it-needs-to-be UI is the biggest reason I love it over GitLab and GitHub. I've been working in Gitea via a friend's instance for a while, fell in love with the UX enough that I've started the process of working on my own instance, and will be migrating my projects over soon. I wholeheartedly understand the need to avoid cluttering the UI. However, I think that this change, between the fact that it only actually shows up when filled, but provides a very important service, falls squarely on the "worthwhile" end of this spectrum.
GiteaMirror commented 2025-11-02 06:58:30 -06:00
Author
Owner
Copy Link

@techknowlogick commented on GitHub (Oct 5, 2023):

Re-opening as we now have the user key/value table which means this could be implemented without needing a migration or another column.

@techknowlogick commented on GitHub (Oct 5, 2023): Re-opening as we now have the user key/value table which means this could be implemented without needing a migration or another column.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/proposal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#6522
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?