[Feature Request] Terminology change for split keyboards

[rmwphd]

Feature Request Type

• Core functionality
• Add-on hardware support (eg. audio, RGB, OLED screen, etc.)
• Alteration (enhancement/optimization) of existing feature(s)
• New behavior

Description

In recent years, a number of software organizations have been phasing out the "master-slave" terminology once common in databases and some hardware. Some, have replaced it with "master-minion", others with "primary-secondary" or "primary-replica" (better for databases), still others use "leader-follower". Github itself is moving to an alternate term for the "master" branch. I'm not sure which set of terms is most appropriate for QMK, but 2020 feels like as good a time as any for us to start considering the answer to this question.

Overall, this should be a reasonably simple change that helps ensure that everyone feels welcome to contribute to qmk development. I've started a naïve attempt to replace the word "slave" with the word "follower" across the entire repo. I'll link my PR. The technical problem I'm running into is that running make all doesn't finish without errors, as it should according to the Contributing Guidelines doc.

Can anyone help figure out what changes in my PR break things? Also, I think the qmk community should have a voice in determining the best replacement term(s), so please chime in with thoughts on that subject, as well.

[RossBarnie]

I think a reasonable upgrade path here would be to introduce aliases for each of the offending terms so that we can include deprecation notices, rather than just using find/replace and breaking everyone's forks. I come from a ruby background and it's not uncommon to have something like:

def old_function_name(*args)
  puts "DEPRECATION WARNING: old_function_name is being deprecated in a future release, please use new_function_name instead"
  return new_function_name(args)
end

So the old function still works as expected but it presents a warning to the developer each time it is used. In our case I imagine we'd have it as a compile warning (I'm new to the project and a C project of this size so happy to be corrected).

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs.
For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

[stale]

This issue has been automatically closed because it has not had activity in the last 30 days. If this issue is still valid, re-open the issue and let us know.