Non-inclusive gender options in custom interfaces example

[playertr]

The custom interfaces example in the Beginner Client Libraries tutorial represents gender as a bool, spelled out to be either MALE or FEMALE. ROS users who may have different gender identities may feel excluded by this choice of representation.

bool FEMALE=true
bool MALE=false

string first_name
string last_name
bool gender
uint8 age
string address

I suggest moving to a named-constant enum with an "other" option or removing the gender field entirely. This change is in keeping with the ROS Community Code of Conduct's preference for inclusive language.

I can make a PR after getting folks' input on this change.

[cdhabecker]

I concur. Just remove it.
Also, no one stores age -- always store date of birth.
Also, bool is a poor use case for constants.

Address is complex. How about a basic contact with a phone number? Just a naive, single-number implementation with a type to demonstrate constants.

uint8 PHONE_TYPE_HOME=0
uint8 PHONE_TYPE_WORK=1
uint8 PHONE_TYPE_MOBILE=2

string first_name
string last_name
int32 date_of_birth_seconds
string phone_number
uint8 phone_type

[fujitatomoya]

I am okay to change that, @playertr can you make a PR targets to rolling branch?

[playertr]

Okay, I'll make the PR.

[playertr]

Okay! I submitted a PR (and I think I followed GPG signing and commit-message conventions -- couldn't find one).

#3558

I also deleted the age / date of birth field because IMO the best representation for this field would be a std_msgs/time message, and creating one is outside the scope of this tutorial.