“Non-binary” is another relatively inoffensive term. “Other” is used as a value so generically that it could not be recognizable on its own.
Meanwhile, “Fran Smith, non-binary” implies the category of characteristic nearly as well as “Fran Smith, male” does.
I agree with Brian. Non-binary is how I would word it.
OK. We can have the values “Male”, “Female”, “Non-binary” and “Unknown” for the Sex field.
What options do we want for the Gender field? Is “Gender” the term we want to use?
Shouldn’t our internal docs also list ‘null’ as a possibility too?
Will users be able to override the value of the sex field on a case-by-case basis? If not, “Other” seems safer than “Non-binary” because it is more generic. Regardless, if I ever had to use it, I would probably also add a Note with an explanation.
The Gedcom standard defines only four values for Sex.
“X” is defined as “Does not fit the typical definition of only Male or only Female”.
We could use the full description, but I thought that it might be neater to have a shorter entry in the drop-down list.
That’s a can of worms.
Perhaps it would be best to start with an absolute minimum of built-in custom types… just enough to indicate the field is a custom type list.
And we would create framework Person CML that people could download & import (or just past into the Import Text Gramplet ) to expand the Custom Type list with an evolving list of standardized terms.
Currently the interface shows (for example, in the People category view) lowercase values of “male”, “female”, and “unknown”. I understand the codes M, F, X, and U are set by the GEDCOM standard but my question is whether users wold be able to choose to show “other” for X. I guess they would not be able to change it on a case-by-case basis.
Also, the interface currently shows (for example, in the Relationship category view) the symbols 
︎ and 
︎ for male and female. Is there a recommended symbol for X?
The discussion has leaned towards continuing to use the standard 4 choices offered by GEDCOM exactly as before.
But, if “X” is selected for Sex, another “Gender” user interface selector expands near the Sex choice. (Similar to the way the Multiple Surnames expands the surname selection.) That would offer the Custom Type list & date range.
In this way, the interface remains unchanged & compact for the vast majority of entries. AND it avoids probable ultra-conservative backlash.
One imagines that the Genealogical Symbols interface could be expanded to allow symbols & color swatches to be associated with Custom Types. No matter what color or symbol the project chooses, someone will take offense. So might as well let them be angry at themselves.
Sorry if I’m confused. Here’s my understanding of the discussion so far, as it would affect the Person category view. Please correct me.
The values “male”, “female”, and “unknown” would appear in the column previously labeled “Gender” but now to be labeled “Sex”. A new value (“other”?) would also appear in this column when the code is X.
A new column labeled “Gender” would display whatever new standard and custom values are decided for that new field. (Or are you saying its value would appear in the Sex column instead of “other”, only when that field’s code is X, and there would be no Gender column in the view?)
Instead of “Other” how about “Neither”?
Actually this is wrong, the term Intersex should be used. Please see the Wikipedia article.
I should think the first three enumerated values would be Unknown, Male, and Female to align with the Sex field and because Male and Female are the two most common genders. Why would you leave them out?
A label change is negligible (considering how Weblate can be used to tweak those.) As is an additional menu list item.
And the new “Gender” element could appear in any number of ways. (Columns, rows, expanding sections… whatever.) Leaving the developers room to innovate seems wise.
Wonder if the statistics gathering for sex guessing would have to be tweaked? (Although it’s probable that none of the X or U sexes will be in the majority of any name cropping up multiple times. So tweaks there may be work to no purpose.)
I would not do this. The interface should prompt for the Gender as it does today, and then the Sex field should be populated based on that selection. 90% of the time the user will select unknown, male or female. When they don’t the logic to populate the sex field behind the scenes would use x.
You might then, if the user selects a non-binary gender, have a user configurable option as to whether then the Sex field should pop up if they want to change it from X to one of the others.
Because I suspect that we haven’t a clue how people would want to document an X.
What would “Sex: X; Gender: Male; Date: before Mar 1980” even mean? Born male? Post-op: Man? Transgender Man?
Born Intersex, identifies as Male. What’s hard about that?
Oh. Yeah. Hiding Sex and just entering Gender won’t work. Scrap that idea. Perhaps you just always need to show both regardless and insure you use the label “Birth Sex” to qualify it. And instead of using “Gender” as a label use “Identifies As”?
In trying to think about this issue, my thoughts naturally turned to how this could/would be implemented for an individual.
We would have the current field Gender repurposed to Sex with the biological options:
Female F ♀
Male M ♂
Other X ⚥ or ⚧
Unknown U ⚪ (I like ◌ \u25cc)
We would then add a new Gender field with the cultural options:
Woman
Man
Trans Woman
Trans Man
Non-Binary
Unknown
Do we post the symbols based upon Sex or Gender?
Is the Gender field grayed out and only becomes available when Sex: Other is selected??
And is there really a need for a date option? There is a date for a legal name change or for any medical transformation, but those dates would not signify any date certain for the individual declaring they are a Man or a Trans Man. Those born what society would classify as Female do not suddenly on a date certain declare “I am now a Man.” For most (all) people they would say they were always a Man trapped within a woman’s body.
Woman
Man
Trans Woman
Trans Man
Non-Binary
Unknown
Is a really bad idea. That is classifying a trans woman as something other than a woman, and a trans man as something other than a man.
Related: cisgender and transgender aren’t genders. Those are classifiers for gender.
This is an exceedingly complicated subject, even among trans and queer people. Whether people “identify as” or “are” LGBTQIA and whether those identities are mutually exclusive or overlapping or … I know people who are non-binary men. I’ve met male lesbians. There’s ideas of social transition and legal transition. Some people who code switch depending on which groups they are part of. I know one person who is female for work, and male socially.
I’m not saying everything can be accurately recorded. I’m saying this is something worth consulting trans orgs, as I posted a few days ago. Making the effort will avoid a lot of pitfalls, however. (For instance, it is also a bad idea to base pronouns for reports on sex or gender fields.)
Phil.
Do we post the symbols based upon Sex or Gender?
Interesting question, it affects the person color scheme as well for things so that also will need to be extended.
I think perhaps that should be a user configurable option and should not be set in stone. Not everyone will be in agreement.
Having said that, I think Gender should be the default option though as it reflects who the individual is or was which is the more important fact of the two.
Is the Gender field grayed out and only becomes available when Sex: Other is selected??
I was not thinking clearly earlier, I think both fields must always be available. We should simply be providing a means of recording the facts, how the user chooses to then record them is their choice.
If Sex is changed and Gender is unknown, we may want to set it to match, and then the user can change it as needed from there.
I think we probably do not need a date. Dated attributes might have been approach, but forget that. That could always be revisited in the future, but you are right there are other ways of recording those things if someone thought they were applicable.
At least those are my thoughts.
The date could be leveraged by report generators.
Like the Name has a date range and paragraphs generated for events intersecting that date range would use the Name that matches, the pronouns can match the events described for intersecting gender identity.
So a person (who marries & has children before changing gender identities) will have a couple gender identities. One before & another after divorce… and maybe another post-op.
So, like the Multiple Names, there’s a preferred and as many others as necessary.