Need more Gender choices for person info

[ChurchCRMBugReport]

Just getting this out as a feature request, knowing it's going to be controversial for some: Adding and editing persons in the database, and need more choices for Gender than the current binary male/female (or not specified). It's the 21st Century now and many of us are fully inclusive of people with nonbinary gender identities, and 'not specified'/none is NOT an acceptable option (neither respectful nor informative/helpful). Even adding 'other' to the list is alienating. Perhaps adding 'nonbinary'? We've already added a custom field for 'pronoun':'he/she/they', which is much more helpful information in any case.

Collected Value Title	Data
Page Name	/PersonEditor.php
Screen Size	900x1440
Window Size	781x1440
Page Size	2341x1440
Platform Information	Linux vshare5.ezp.net 3.10.0-714.10.2.lve1.5.19.3.el6h.x86_64 #1 SMP Tue Aug 7 22:19:36 EDT 2018 x86_64
PHP Version	7.0.33
SQL Version	10.1.38-MariaDB-cll-lve
ChurchCRM Version	3.3.1
Reporting Browser	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Firefox/67.0
Prerequisite Status	All Prerequisites met
Integrity check status	{"status":"success"}
Apache Modules	mod_rewrite,mod_mime,mod_headers,mod_expires,mod_auth_basic

[crossan007]

Despite any possible theological disagreement by any users or contributors of this application on this matter, our first commandment is to love and to serve others with honor and respect. Having a system that allows for accurate records is critical to performing the above tasks.

This is a feature that we will implement. I can't give a timeline on implementation, as I've been personally stalled on contributing, but PRs are certainly welcome.

[crossan007]

I imagine the change would look something like this:

• Add a table for GenderOptions, prepopulated with the current available set of options
• Alter / update the current field so that the current "binary" per_Gender field serves as a foreign key to associated gender's primary key (https://github.com/ChurchCRM/CRM/blob/master/src/mysql/install/Install.sql#L647)
• Update all ORM logic to remove IsMale() to an appropriate method name (https://github.com/ChurchCRM/CRM/search?utf8=%E2%9C%93&q=isMale&type=)

[crossan007]

I think there may be instances where "patriarchal" family types are assumed within the application logic. I don't know offhand where these are located, but we'll need to address these as well.

[MrClever]

If we adopted this, I would rather see an option to disable it too. There are some very strong theological issues here (on both sides) and adopting this without an option to disable it, would alienate quite a few churches. I've been out of the loop a bit on this one due to my daytime commitments so apologies for the late submission.

[boluak]

I have very strong issues against and vehemently protest the addition of this option (gender choices).!!!

Just getting this out as a feature request, knowing it's going to be controversial for some: Adding and editing persons in the database, and need more choices for Gender than the current binary male/female (or not specified). It's the 21st Century now and many of us are fully inclusive of people with nonbinary gender identities, and 'not specified'/none is NOT an acceptable option (neither respectful nor informative/helpful). Even adding 'other' to the list is alienating. Perhaps adding 'nonbinary'? We've already added a custom field for 'pronoun':'he/she/they', which is much more helpful information in any case.

[MrClever]

@boluak - without an option to disable this, I know a few churches I’ve deployed ChurchCRM for who will be immediately moving to alternate platforms. They have told me. This is sad for the project, but with this change being very likely to create strong dissent and division within this project and the churches it serves, I honestly don’t see a path forward that forces it on users. I have heard your sentiments from other churches and I don’t believe we should ignore our customers.

An option to “enable non-binary gender support” (eg bEnableNonBinaryGender the “People Setup” screen) would be a far less confrontational path which wouldn’t change existing behaviour and still allow admins to have support for non-binary genders. Then, the code branches which display the non-binary options would only be traversed if the option is enabled. As a first-step this maintains existing behaviour at the cost of some additional code complexity.

Alternatively, creating a new table with genders and their associated pronouns would allow admins to construct whatever plethora of “genders” they deem appropriate, but ship the product with the existing male/female behaviour (as described by @crossan007 above). The drawback with this approach is a fairly wholesale rewrite of the way genders are handled and a new screen for editing genders/pronouns etc. would be required. However, I think this is the option we should be working toward as a “final” solution which would also avoid the need for an enable/disable flag in the setup.

Whatever my personal views are on this matter, the reality is our customers have expressed a high degree of resistance to this change being “forced” on them. Consequently, I propose we park #4853 until we have a solution that allows the existing behaviour to be maintained by default with the non-binary gender configuration being something admins enable/facilitate on their own.

[troysmith31]

I agree with creating a new table to allow end users to maintain a custom gender list.

[boluak]

I exercised a strong restraint, didnt want to turn this into a never ending debate, hence my one line submission, which i guess could have been misunderstood. @MrClever thank you for stating this in simple words above. brlliantly expressed my situation/stand I'm from a very large denomination originating from a third world country in Africa, and I'm still trying to "sell" CCRM to other parishes. It would indeed loose all credibility, the worst of it is that most people would not say a word, they will just quietly remove the application....

To safeguard the future of this project I will like to highlight a few points.

1. where is this "request" coming from? I honestly dont know! I'm just seeing a churchcrmbugreport.
2. Does it mean that anybody even a "satanist" will submit a request and we will jump onboard and implement it, and to what end? that is if we should not shy away from alienating, or seem unsupportive of satanists anyway.... there had been a few requests, good ones too, submitted by people we have come to know, that are not divisive, yet nobody has had time to implement. why is this being rushed in?
3. Who is CCRM being developed for- target users? who are they and what are their likely use-case or wishes
4. Do we have any sort of rules/guidelines (theological/doctrinal or otherwise)as to the direction this project is heading? or what is the foundation we are building it on? strictly biblical or social- like facebook with its 58+ gender classifications as against the biblical "male and female created he them" Gen 1.27 (KJV) what sets the church apart from the world? In the short time I have spent with the project, I have seen the lead developers standing on firm ground concerning their coding standards and were not moved/pressurised to abandon it. so if there are standard or rules?........

I bid you remember, a little leaven, leaveneth the whole lump, (1Cor 5.6) (KJV) @MrClever suggested an apparently very good solution to this case but where do you draw the line, where will it end... same sex marriage, marriage between human and animals?- pardon my lack of political correctness.

remember sodom and gommorah- totally wiped out, remember the tribe of benjamin in (Judges 19-21), nearly wiped out... and a host of other examples in the bible... it all began with a little innocent step.

From the time of Moses, to the days of sodom and gommorah, and the time of Paul the apostle, God's stand on this subject has not changed, why do we think he has changed now in a mere 2000 years? or with public opinion or because of the laws of governments and empires that gets overthrown at the drop of a hat!

Enough said... wouldnt turn this into an endless debate.....

[crossan007]

@boluak Thanks for your comments. I also am not looking to argue, and I expect any additional discussion to proceed as respectfully as the preceding :-)

My approach, and response on the matter is roughly as follows: Whether I agree or disagree with the theological implications of non-binary genders does not matter and is not the focus of discussion here. The reality is that there are plenty of churches that do "welcome all," and having the capability to store the relevant metadata about their congregants may enable those churches to better serve their congregation with love.

I do question how the presence of this feature in the software would cause the software to "lose credibility" in the eyes of church management - this application is primarily a tool for church management's use to better serve the congregation; it is not something that is teaching / leading the congregation in the ways of God or otherwise instilling doctrine to the Body. Can we expect every piece of software every service and every tool in use by a church to align with the theology of the organization?

If there are concerns about the scope of exposure (i.e. the person and family self-registration pages, etc) that non-binary gender code affects, that is a perfectly valid concern, and I feel is well addressed by @MrClever (having a system-administrator level configuration to enable/disable the relevant code paths)

there had been a few requests, good ones too, submitted by people we have come to know, that are not divisive, yet nobody has had time to implement. why is this being rushed in?

I share your sentiment - I wish I had more time and energy to work on all of the feature requests that folks have submitted.

I do not agree that this is being rushed in - as I mentioned in my original post, I've been rather stalled on contributing to this project for personal reasons, and I'm not in a rush to implement this. I'm certainly not in a rush to cause sweeping divisions between contributors and users of this project. I said that it's something that would allow churches to better serve their congregations, and therefore should be included.

Do we have any sort of rules/guidelines (theological/doctrinal or otherwise)as to the direction this project is heading?

Not formally, although I think it could be best summarized as: ChurchCRM exists as a tool for church management to use to better manage the information regarding the congregation they serve.

[chiebert]

For the record, I'll own up to submitting the original bug report from within the application (since that adds important technical and version data, as as you know), and I regret not immediately adding a comment here to de-anonymise it. It's been a busy few months serving as a minister in Christ's Church and I haven't had a chance to check back since the original post. Thank-you, @crossan007 for your helpful comments and @MrClever and others for suggesting and working on a solution that makes the platform more helpful for the full spectrum of the Church.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 15 days with no activity.