This was where my thinking was earlier by maybe extending attributes with a date and using those. My use of the “preferred” term was in reference to this.
Whether an attribute or other new secondary object entity, one of those entries would need to be flagged as the Birth Sex, and be the one used in Gedcom exports/imports. There would then be a sex_index that would point to the preferred one to be used in displays and reports. And Gender could be treated the same way. This would provide the most flexability as not everyone will agree on what should be provided or done.
Do you think Brian’s earlier suggestion that maybe Gender be tied more directly to Name in some way makes sense?
It makes some logical sense, and I can see pros. but I would not lean that way for a couple of reasons:
it makes name and sex/gender interdependent and as a person who writes software in my day job, keeping things independent is less risky. once they are tied to together, it’s hard to untie them if it turns out that it’s a bad idea.
people who change their perceived gender expression often change their names (hence the term “deadname”), but it isn’t always done at the same time. Sometimes folks try out a few names before they settle on one. Or they realize they were always X gender even if they presented as Y gender under a former name. What gender do I put with a birth name then? So while there’s a fair amount of pairing between name & gender, I would probably just enter them separately. E.g., Elizabeth transitions and becomes known as Dwayne. It’s a little extra work to enter the date & notes for both names and gender entries, but i could use different times, notes or citations.
maybe a good way to illustrate is occupational names (e.g., stage names, royal names, and religious order names). Martin Sheen is very much tied to Ramon Estevez’ profession as an actor, but I don’t know exactly when he became an actor. Did he have some credits under his legal name? And he still goes by Ramon in his day to day life, yet he’s still an actor. Other folks use their stage names for the rest of their lives even though they don’t remain in acting. Probably gives me more freedom I enter names and Occupation events separately, even if a lot of the documentation overlaps.
(Side note: might want to introduce a special type of name called “Deadname” that is by default private and/or can’t be used as the primary name. I.e., keeps it out of reports. Publicly using someone’s deadname is a cause of angst for many trans people. As a genealogist, there’s value in have a record of it, but I’d want to keep a lid on its use. Something I can do right now by marking a name as private, but I could also forget or accidentally revert back to public.)
@Nick-Hall what are your thoughts on an approach where we add a sex_list and gender_list to the Person object, with birth_sex_index for birth sex, sex_index for preferred sex, and gender_index for preferred gender?
The Sex and Gender objects would be very similar, the only difference being their type as it seems like we should keep those separate. So they would both have type, date, citation_list, note_list and private.
This seems like it provides the most flexibility for people to document things in the manner they would like.
The gender it’s not a topic unless since some few decades.
In the past, birth wasn’t a topic for priests. We can add, or not, a birth event and date when we only have a batism event and date. It could be the same thing for the gender now. That notion is known/recognized only recently.
If the gender field is always there, you could add a “not applicable” (or a “no information”) default entry (wich is not unknown) because 99% of genealogies entries, well I guess, this topic has no information and even less source to support this topic.
If it’s a field which can be added when needed, the subject does not arise. My preference.
Would it be better just to enhance the existing attributes? The Gedcom standard already allows a date. We would also need to add a type.
The type for existing attributes would be str. For the new gender field it would be a GrampsType maybe called GenderType for example.
The types int, Date and also a type for Gramps objects such as Place could be useful in the future for adding things like a population attribute to places, or even replacing the date and place fields in events so that they could have notes and citations.
With this approach, adding a new attribute for sexuality in the future would also be easy.
I think I like that. Would it mean that events could have more than one place attribute? For example, a single “Voyage” event with places and dates for the start and end points. The citations could be different for the start and end points, based on different passenger lists for each (e.g. Hamburg departures vs. New York arrivals).
Yes we could do that, that was my initial line of thought.
If we do this I think we should consider that attributes can be applicable at either a point in time or over an interval which can span up to the lifetime of the subject. So I think a start_date and end_date would be needed and not a singular date. And maybe an indicator if it should be interpreted as singular or a span if there is only one date provided.
Yes. I was also thinking that you could record two places from two different sources. If they were contradictory then the one with the highest confidence level could be used.
It would also be possible to have different sources for the date and place. I’m not sure about having a Date type attribute which would also have a date. This may need more thought for some future applications.
A comment on the voyage example: I don’t think having multiple place and multiple date attributes would help here, as each stop of the voyage would have a place with an associated date.
So what would make more sense to me would be to treat events as hierarchical exactly as we do for places. Just like places have a place_ref_list, events could have an event_ref_list (as people and families) for parent events.
The voyage would than be an event with a span as date and either no place or something generic (Carribean sea), and the stops in individual ports would be child events with fixed date and place.
Another example would be a marriage event that has two child events, the religious service with a place of worship as location and a celebration in a different location.
Concerning the topic of the thread (sorry for veering off topic), one issue that I believe hasn’t been discussed so far is that there are languages (including at least German) that have one and the same word for “sex” and “gender”. So having two fundamentally different entities in Gramps that are referred to by the same word in some languages might be tricky for internationalization.
Final comment: why not just use the existing Event object type instead of attributes with dates? We already have things like a “Religion” event that can have a date but don’t really need a place. Same could go for a “Gender” event.
Heirarchical events are a good idea and needed, they have been brought up here before by others as I recall.
I was unaware of the internationalization implications around gender in some languages but that makes sense now that you point it out.
In my mind I think the line between attributes and events seems ill defined. To me an attribute is a characteristic about an individual and an event is generally an experience the individual undergoes or participates in. Both can be at a point in time or over some duration. From that perspective sex and gender are attributes, so are some other things classified as events like religion, number of marriages, medical information, cause of death, property, even occupation.
I decided to give Gramps a go this evening to start building out my family tree and… I immediately slammed into a brick wall trying to start with my own record. When I went to save a record with just my name, it informed me that I omitted a gender and that “usually, this is a mistake”. Neither of the options it gave me (“Male” and “Female”) are accurate descriptions. For now I am leaving it as “unknown” even though this is incorrect and the software is upset at me for doing so.
The behavior of the software was upsetting, but I was grateful to find that the issue is already being discussed. I appreciate the great deal of thought being given to solving the issue in the discourse above!
I do think it’s worth noting that almost any of the solutions discussed above are better than the current user experience. Right now, it isn’t possible to even start my family tree without entering incorrect information about myself. While I’d love to see a modern, thoughtful approach toward identity in a future version, I think it’s important not to let “perfect” get in the way of “better”.
Would it be feasible to split this discussion into 1) what can be done to fix the problem in the short-term, and 2) what can be done to most accurately record information moving forward?
I propose that as a minor fix to the currently-released software version:
Add an “other” or “custom” option to the list of known genders
Add a corresponding notes/description field that allows free-text to describe what “other”/“custom” means in this context
For future versions, make more substantial changes that treat gender as a part of the identity that is not static:
“Assigned gender at birth” seems the correct way to describe what some would call “birth sex”
“Gender identity” seems the correct way to describe the actual gender of the individual
Mirror the structure of name data for gender since names also follow a “name at birth”, “preferred name”, “also known as”, etc. progression. It would also allow more complex descriptions such as someone who identifies as “trans” and “non-binary” and “demigirl”. Multi-category identities like this are increasingly common
Hide deadnames from exports, as suggested above (thanks @kingrat!)
Last point… while I appreciate the importance in continuing to support the GEDCOM specification for compatibility, its limitations should not limit Gramps. The GEDCOM specification seems to be owned by FamilySearch which is explicitly part of the LDS Church. Since the LDS Church is anti-trans (does not recognize anything other than gender assigned at birth), GEDCOM may never support correct entry of information for trans and nonbinary folks. How to handle the export of such information to GEDCOM is worth discussing, but it should not limit the ability of Gramps to handle this information more correctly internally.
If there is agreement that a short-term fix can be implemented while a longer-term strategy is defined for a future release of the software, where would this effort start? Is there already code that can be tested and merged? Or would creating a short-term fix PR for this issue be a good place for me to contribute?
When it comes to Gramps and following GEDCOM, It might have to follow it on some data fields,I dont really know much about that.
But I dont think Gramps should not implement a new field because GEDCOM doesnt have it, you could just make it so that when you export, its exported as an attribute field instead.
Unfortunately, it is not an easy hack of the code. And as you probably read here there are many ideas of where/how in the GUI the new Gender field will be found. The current Gender field will be restructured to Sex with at least a fourth option: X = Does not fit the typical definition of only Male or only Female, or Non-binary.
As you probably noticed, users have posited many options to be included in the new Gender field. Much of coming from positions of ignorance and in an attempt at learning about going beyond the binary concept on Man/Woman.
You as a non-binary genealogist could educate us as well as help steer us in what is actually needed to fully document a person’s genealogical record.
Adding an extra option to the existing field would be the easiest change.
Adding a notes/description field is more difficult because it involves a change to the data model. The same applies to changing the current field to a GrampsType which would allow custom entries.
Names can be flagged as private, so deadnames don’t cause a problem.
We use the sex/gender of a person in a few ways: to display a colour in charts, to display a symbol in reports, and to determine pronouns in narrative text. At what level do we define colour, symbol and pronouns? We may be able to use the same colour and symbol for all non-binary genders, but we will need to know which pronouns to use in narrative reports so these should probably be defined at a person level.
Next we have to consider translations. Do we want a list a pre-defined genders so that they can be translated? We will probably also have to investigate how the pronoun options translate.