In database design the most important thing you do is decide what the "entities" are of whatever it is you're trying to create a structure for. A "person" is an entity. A "project" is an entity. A connection of one entity to another entity is an entity of its own. For example, if person1 is working on project1, along with other people, then that particular connection is an entity in a project-people "join" table between People and Projects. This join table could also have a field, "role", where you could have attributes values like "volunteer" or "researcher".
But gender is an intrinsic attribute of a person. I can see no circumstance ever where a gender would require a table of its own.
I can see a table of "genders", where you would have only 2 records, one with gender = "male", and one with gender = "female". This table's only use would be to filter genders from something like the People table. But the same thing can be accomplished using an unstored text field, _cMale_txt = "male" (etc. for female), in the People table itself, and a self-relationship using that field. That is what is usually done.
I think that's why you're having trouble. It is not proper relational design, in my opinion. It may seem to solve some immediate need, but creates more problems than it solves.