Quantcast

gender same sex

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

gender same sex

Benny Malengier
Hi,

I would like to discussĀ GEPS 027: Gender as an Entry Field (http://gramps-project.org/wiki/index.php?title=GEPS_027:_Gender_as_an_Entry_Field ).

What to do? I'm concerned about the mapping to GEDCOM, and the reporting based on gender, and would like to keep gender simple for that reason.
If you read the GEP, the proposal is clear:

Prop 1. Gender as Entry Field.
This seems a simple enough solution, but does complicate things for the majority. It also does not solve the symbol issue.

Question: With what would be prepopulate that? I assume only unknown, male, female.

My own suggestion would be:

Prop 2:
Extension of Gender with Other. If Gender is Other, then two new fields become available: Gender Specification, which is a text field, and Gender symbol, which is also a text field of max three characters

On one hand, this seems a lot of trouble, but on the other, it does not introduce the full complexity of a custom entry field. Gender remains a simple 4 choice which should not create too much issues in converting. The different gender people still have the possibility to enter their gender in more detail, and select a custom symbol.


Apart from gender issues, I assume this proposed change is not meant for the indication of transsexuals? I assume for transsexuals, a researcher could store a gender as male/female, and add an event 'Gender change' or something like that if he wants to store the fact.

I feel we should decide on this GEP to move forward or not, so as not to bad feelings afterward.

Bennyn


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gender same sex

DS Blank
On Thu, Aug 23, 2012 at 4:53 PM, Benny Malengier
<[hidden email]> wrote:

> Hi,
>
> I would like to discuss GEPS 027: Gender as an Entry Field
> (http://gramps-project.org/wiki/index.php?title=GEPS_027:_Gender_as_an_Entry_Field
> ).
>
> What to do? I'm concerned about the mapping to GEDCOM, and the reporting
> based on gender, and would like to keep gender simple for that reason.
> If you read the GEP, the proposal is clear:
>
> Prop 1. Gender as Entry Field.
> This seems a simple enough solution, but does complicate things for the
> majority. It also does not solve the symbol issue.
>
> Question: With what would be prepopulate that? I assume only unknown, male,
> female.
>
> My own suggestion would be:
>
> Prop 2:
> Extension of Gender with Other. If Gender is Other, then two new fields
> become available: Gender Specification, which is a text field, and Gender
> symbol, which is also a text field of max three characters
>
> On one hand, this seems a lot of trouble, but on the other, it does not
> introduce the full complexity of a custom entry field. Gender remains a
> simple 4 choice which should not create too much issues in converting. The
> different gender people still have the possibility to enter their gender in
> more detail, and select a custom symbol.

Benny,

I think that this will be a nice addition to Gramps, and brings it
into the modern world.

What is the argument against making it like all of the other
GrampsTypes, including allowing Custom with text? It seems that that
would allow most of what anyone would ever want, and is already a well
understood concept.

We could have a separate utility for associating a symbol for
different custom values (perhaps just in the config file... how many
people would actually want to change that?)

-Doug

>
> Apart from gender issues, I assume this proposed change is not meant for the
> indication of transsexuals? I assume for transsexuals, a researcher could
> store a gender as male/female, and add an event 'Gender change' or something
> like that if he wants to store the fact.
>
> I feel we should decide on this GEP to move forward or not, so as not to bad
> feelings afterward.
>
> Bennyn
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gender same sex

Benny Malengier


2012/8/24 Doug Blank <[hidden email]>
On Thu, Aug 23, 2012 at 4:53 PM, Benny Malengier
<[hidden email]> wrote:
> Hi,
>
> I would like to discuss GEPS 027: Gender as an Entry Field
> (http://gramps-project.org/wiki/index.php?title=GEPS_027:_Gender_as_an_Entry_Field
> ).
>
> What to do? I'm concerned about the mapping to GEDCOM, and the reporting
> based on gender, and would like to keep gender simple for that reason.
> If you read the GEP, the proposal is clear:
>
> Prop 1. Gender as Entry Field.
> This seems a simple enough solution, but does complicate things for the
> majority. It also does not solve the symbol issue.
>
> Question: With what would be prepopulate that? I assume only unknown, male,
> female.
>
> My own suggestion would be:
>
> Prop 2:
> Extension of Gender with Other. If Gender is Other, then two new fields
> become available: Gender Specification, which is a text field, and Gender
> symbol, which is also a text field of max three characters
>
> On one hand, this seems a lot of trouble, but on the other, it does not
> introduce the full complexity of a custom entry field. Gender remains a
> simple 4 choice which should not create too much issues in converting. The
> different gender people still have the possibility to enter their gender in
> more detail, and select a custom symbol.

Benny,

I think that this will be a nice addition to Gramps, and brings it
into the modern world.

What is the argument against making it like all of the other
GrampsTypes, including allowing Custom with text? It seems that that
would allow most of what anyone would ever want, and is already a well
understood concept.

We could have a separate utility for associating a symbol for
different custom values (perhaps just in the config file... how many
people would actually want to change that?)

Actually, in my suggestion, I would even suggest not to do a database. The Gender Specification andĀ  Symbol would just be two attribute types you then can enter on the main interface instead of the attributes tab when other is selected (they will be visible also there however, so source can be added there). So no database upgrade at all. Putting them in the attributes is how we should support storage of it in Gedcom anyway.

In family editor I would also keep it GUI only to set that people are not man-women family (how to call that in a checkbox however, 'same sex family' does not sound right to me, but neither will people like something like 'non-conform family', as it shows a bias.

It just does not sit good with me to have gender something custom, so somebody could type 'lala' and then having that exported to all reports. I think this is a field we should actually know what people can enter, and list all the possibilities. If somebody could list all the types of other genders, we could still have a combobox. As that does not seem likely, showing other as combo, with the option to specify, seems like the next best thing to me.

Benny


-Doug

>
> Apart from gender issues, I assume this proposed change is not meant for the
> indication of transsexuals? I assume for transsexuals, a researcher could
> store a gender as male/female, and add an event 'Gender change' or something
> like that if he wants to store the fact.
>
> I feel we should decide on this GEP to move forward or not, so as not to bad
> feelings afterward.
>
> Bennyn
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gender same sex

Tim Lyons
Administrator
I tend to agree with the discussion page on GEPS 027:

"My concern here is that this idea conflates two separate pieces of information: Sex (biological context: XX or XY), and sexual identity (social context: how they view themselves sexually). I have no objection to adding a field for sexual identity (or orientation), which would necessarily be an entry field, but do not agree with having it replace the existing field for biological sex. To do so would leave it impossible to capture both the biological and social aspects of a person, just as it is currently. In short, it would be just as wrong, but in the other direction."

Tamura seems to think that "U" for "unknown" would be a legal GEDCOM value, but I don't see any support for that in the standard. There only seems to be M or F, despite the fact that it allows up to 7 characters.

If you want to make a change, then Doug's suggestion to treat it like the other GrampsTypes, including allowing Custom with text seems the least disruptive. (This would allow the user to input XXY or XXX for example). See http://en.wikipedia.org/wiki/Intersex#Conditions. Perhaps some guidance should be provided to encourage users to decide for their own database whether they are going to record genotypic (chromosomal) and phenotypic sex, or something else such as sexual identity in the existing field.

Adding another field to the already crowded individual input screen seems complicated and unnecessary for the majority of cases. If one wants to separately record sexual identity, then this could be done with an attribute.

I am not sure why the title of this discussion includes the words "same sex". This seems to imply that it is related to the discussion about how to insert same sex marriages, but again this is an entirely different topic.

My favoured option is to provide guidance to user that they should decide for themselves what they are going to record, and if the existing fields is inadequate for that they should use one or more attributes.
Loading...