In most CRM systems, especially older ones, and ones that are less flexible, some fields can be points of contention for some of us. Gender is one, marital status is another.
CiviCRM, to it’s credit, allows for an arbitrary number of genders – you can define them however you like. My bet (although I could be wrong) is that it’s one of the few out there that allow that. Gender is not a standard field in Salesforce.com contact records, so if you want to add your own, you can customize it however you’d like. There was a very interesting and lively discussion about the gender field in Drupal profiles. Of course, one can always customize these things in Drupal.
For a couple of projects we’ve been working on, we’ve been getting very interested in putting together a really expanded and fleshed out data model for gender, sexual orientation, and marital status. Here’s the first draft. We’d love feedback on this (besides “this is silly/too radical/dangerous/from the antichrist/etc.”). And we also know that even for those who agree that sex and gender are different things, people will differ on how to divide these categories and make sense of it.
- Sex: Male, Female, FTM, MTF, Intersex
- Gender: Male, Female, Genderqueer
- Sexuality: Gay, Lesbian, Bisexual, Queer, Questioning, Straight
- Marital Status: Straight Marriage, MA, DC, IA, VT Domestic, CA-SF 2004, CA 2008, Canada
- Relationship Status: Single, Partnered, Divorced, Dating, Poly (There probably could be some field dependencies of Marital Status on Relationship Status)
And if you maybe thought that OpenIssue headquarters was in San Francisco, I’m sure this list made you sure. (Yes, we are.)
{ 13 comments }
I’m bi/queer and married to an opposite-sex partner. It would feel wrong to me to describe my marriage as a “straight marriage” (for lots of reasons), even though most people see our marriage that way. I’d like to see an “opposite-sex marriage” option, if there’s not a better term. Having the separate relationship status field in addition, as a qualifier, is helpful.
Good point! That categorization of “straight marriage” status does in fact imply sexuality, doesn’t it? As you point out – that’s not necessarily right. “opposite-sex” marriage I think works better. Another question is which of these are radio buttions, and which checkboxes (select all that apply?)
Data’s just data until it’s information. If you make these categories too broad, then they become meaningless. How would these values be useful to your customers?
Thinking from the perspective of one very large customer of similar databases (a major political party starting with “D”), I can’t see where I’d ever want to do a query for all MTM, Questioning, VT Domestic individuals in Illinois. Honestly, I don’t think I’ve ever used gender in a query, and I’d only ever use marital status to properly address a couple in a mailing or phone call.
Most records for a person should reflect something between how they want to be identified and how some official agency identifies them. As far as gender goes, those are both basically binary. Marital status is more complicated, but “single”, “married”, “divorced”, “widowed” seems a good selection.
The remaining categories you’ve outlined – states/years for marriage, sexuality, and relationship status, seem like things that should be customized per client, just as a client may want to include any other data they can acquire about an individual (response rate to various campaigns, survey results, maybe matching to political donation databases, etc.)
It just seems like the problem is only complicated when you focus on “what does the individual want their database row to *look* like,” rather than “what information will we actually be able to use.”
Great stuff! I clicked through from GReader to make the same point that Johanna did. But in reading through that list again, as well as Dustin’s comment, I think that combining the authority of the marital status with the marital status itself is not normalized. The list of authorities recognizing non-opposite-sex marriages will certainly continue to grow, and your list already leaves off NJ, NH, New Paltz, NY, and other municipalities (such as Philadelphia, where you can register a same-sex partnership, but with very limited benefits). And everything outside of North America. I also wonder if recognition/solemnization by a religious body is a condition which some users would want to note. And then there’s the whole issue of committed opposite-sex relationships that aren’t represented by Straight/Partnered.
So, perhaps Marital Status options could be: Single, Opposite-Sex Married, Opposite-Sex Domestic Partnership, Same-Sex Married, Same-Sex Domestic Partnership, Widowed, Divorced (as a legal status I think this goes here, and “Separated” is the term to use in Relationship Status)
Boolean: Relationship recognized by government
Text: Recognizing authority (Could be a drop-down of States/Territories/Provinces with an Other option)
Boolean: Relationship solemnized by religious body
Text: Solemnizing Denomination
Which of the four authority/denomination fields to use is likely dependent on the mission focus of the organization.
Additionally, as I’m sure you know, “FTM”, “MTF”, and anything with “queer” are politically-charged terms (moreso than others in these lists) that will bug some of the folks you’re trying to include more carefully. I love “queer” myself. Quick personal anecdote – I’m actually closeted about my own bisexuality in my current workplace in significant part because of a lunchtime screed against “people who call themselves queer” by a gay coworker (now former coworker).
Which gets back to Dustin’s point about the line between actionable data in your database vs. how a person describes himself or herself. In our line of work, the challenge is that the line between the constituent and the organizational database is disappearing, with self-managed profiles and sign-up forms. So the choices that are offered to the outside make an important statement to your prospective constituents, and determine what you have on the inside. And these categories are all spectrums with lots of shades of gray and filled with personal stories. How do you select enough points on the spectrum, name them, and present them in a way that honors peoples’ differences while giving you actionable data that you can turn into information that informs decisions that advance your mission? I think that this list is an admirable start, and is useful as a framework to introduce these ideas to clients that might not think of them initially, but that the answer will be different for different organizations.
So one piece of very important context I should have included – this data model is for projects related to speaker’s bureaus that organize panels around sexuality, marriage and gender, as well as marriage equality activists. So for these projects and these clients, this kind of granularity is, in fact, data they need and will use. I agree that in most contexts, this is way too much information. :-)
And yes, @Thomas, you are right, the list of marriage status is incomplete, and will change almost day by day. That is a part that is a bit of a struggle, for sure.
Anyway, thanks @Dustin and @Thomas, these are great comments, and quite useful. I’ll be thinking a lot about how to frame this so that people can use the parts of it that are most useful to them, but have the full spectrum of possibilities to see.
The sex and gender fields feel a bit conflated to me – it almost seems like they’re asking the same information twice. I can understand why you might be interested in knowing biological sex vs. gender identity, but then it would seem better to move the FTM and MTF categories to the “Gender” field instead, only leaving male, female and intersex in the “Sex” field. Although my question would be does your speaker’s bureau require this fine grain of a detail? And if it does, then I’d also qualify the “Sex” field as “Biological Sex.”
To me, it would seem easier to merge the sex/gender picklists into a single “Gender Identity” field, and have the picklist contain all of the following values: Male, Female, MTF, FTM, Intersex, Genderqueer, Transgender, Decline to State. I know plenty of genderqueer and trans folks who would never tick off the “male” or “female” or even the MTF/FTM options, and plenty more trans folks who would never identify as MTF/FTM, trans or genderqueer and only tick off either the male or female options. And plenty more folks who would never comfortably reveal their biological sex regardless of their gender identity, which may also coincidentally match their biological sex. And even a few folks who actively identify as “it,” “zhe” and “hir.” One person I know even identifies their gender as “monster.”
Asking folks sex and gender information is indeed very political, and there’s no perfect solution. However, for modeling your data, at some point you’re going to have to force people to choose something, even if it’s “Decline to State” for the sake of getting accurate reports.
Just a couple more cents for the discussion – hope you’re doing well!
Perhaps it’s purely semantics, but I recommend “different-sex” rather than “opposite-sex.” If we believe that male and female are not opposites, then different-sex makes more sense.
Also, perhaps someone else has already pointed this out, but there’s lots of overlap among Partnered, Dating, and Poly. I guess checkboxes could work where people can “choose all that apply.”
Wow! This is a very difficult and impressive data modelling task, so I just wanted to acknowledge that without necessarily stating any personal opinions about inclusion. I would only add that I think your customer is the best judge of not only their audience, but also the data that they need to collect that will allow them to best serve their customers and their audience. I also agree with ThomasT that the the marital status entity’s attributes may caulse a problem if you want your final design to be normalized. I thought he made some pretty good recomendations. But I am a novice, so don’t quote me. Good luck! very admirable work
Before collecting any of this data, organizations should think about why they want it. “We want to know what [pronoun|title|color envelope]” to use is not enough. “We want to have statistics on the demographics of our community” may or may not be enough. I think this was my favorite point from the discussion on drupal.org (not that there was much to love about that comment thread). Gender, sexuality, and relationship status information can be sensitive, too–we need to think about who will have access to the data and whether we have the ability to protect constituents’ private information.
The context in #5 makes the reasons for these particular fields and options clear–though with the options and combinations available with sex, gender, and sexuality as separate options, maybe simpler options plus a freeform description would make the data both more searchable and more comprehensive.
I also think that putting the fields for collecting this data with other optional demographic information–age, racial identity, religion, field of employment–would demonstrate that it is OK to leave them blank, and that it is understood that this is fuzzy data. “Sex” and “Title” (mr/mrs/ms/dr/etc) fields often sit next to name and date of birth fields, which indicates that they are factual identifiers (not that names don’t change…).
Also, this data isn’t static. Relationship status changes, but so does sexuality and gender identity. Addressing divorced folks as “Mr and Mrs” might be as uncomfortable as addressing genderqueer folks with a wrong pronoun.
Anyway, thanks! It’s great to see how this particular set of information is being addressed. It’s hard to be both a data geek who loves standardized data and a queer who is constantly confronted with “pick one”.
Asexual is missing from your sexuality listing. For that matter, romantic orientation and sexual orientation are not necessarily well-aligned (just as sex and gender are not). I have known someone who was biromantic and homosexual. Distinguishing between romantic and sexual orientations is more common in the asexual community though. Aromantic, biromantic, homoromantic, heteroromantic, panromantic… asexuals all exist.
Use Case:
Case 1
Person born looking male, hence a male birth certificate. Married a woman in 1981. (Mis)Diagnosed as “Undervirilised Fertile Male Syndrome” ie Intersexed Male in 1985. Re-diagnosed after pubertal changes as “Severely Androgenised non-pregnant woman” ie Intersexed Female in 2005. Legally male in one country of citizenship, legally female in the other.
Case 2
Person born with ambiguous genitalia. Birth Certificate says “Sex Unknown”. Passport has X (for Unknown/Unstated) in Sex field, as allowed by ICAO regulations.
These are not hypotheticals, they’re actual cases in Australia. vide Alex MacFarlane, Zoe Brain.
Another use case : That of Christie Lee Littleton. From Littleton vs Prange
Sorry to be a pain, but regarding legal sex, it varies from jurisdiction to jurisdiction, and depends also on context. Thus someone could have a male birth certificate issued by one jurisdiction, but a female passport issued by the same jurisdiction.
It’s not even immutable. Apart from the case of Transsexuality, certain Intersex conditions can cause a “natural sex change”, usually from 5ARD or 17BHDD syndromes.
The situation is similar in some ways to legal databases dealing with jurisdictions allowing retrospective legislation. For those, the query would be:
If I asked at date D1 what the law L1 was on date D2 in jurisdiction J1, what would the answer be?
For this one, it’s more complex:
If in context C1 I asked at date D1 what sex S1 the person P1 was on date D2 in jurisdiction J1, what would the answer be?
Shoehorning in my own situation into your initial proposal:
# Sex: Female AND MTF AND Intersex
# Gender: Female
# Sexuality: Straight
# Marital Status: None of the above (Straight Marriage under Australian Law between two women)
# Relationship Status: Partnered (but celibate – we’re both straight)
Comments on this entry are closed.