our SDLC strategy dictates to always squash PRs to master, but never to stable.  to enforce this:

• we should make 'squash' the default (or only) option for master, to avoid human error, and not have to state that in documentation (i.e. release-to-prod wiki, PR templates).
  we can do that by setting github repo' "rulesets".
  these can be applied per branch, and can restrict merge methods (to only "squash"), as well as the number of approvers - which we might want to do (see attached screenshot).

• -additionally, we apparently have the wrong settings for "num of approvers" - we've set it in the '*' branch protection rule, but not in master. the same goes for "requiring a pull request".-
  -effectively, this means every topic branch must get contributions from PRs, but master is allowed straight pushes.-
  -we should ditch 'branch protection' in favor of the newer 'rulesets' setting.-
  the above is not true anymore - the culprit rule was only effective/available during a recent code-freeze.

• -while we're at it, we might as well remove the option to "rebase and merge" everywhere, if possible.-
  not necessary ATM. master/stable branch rules will suffice for now.

• after all this is done, PR templates and the release guide wiki need to be updated accordingly, to remove instructions on choosing the merge-method.

references

• the slack thread that spawned this task
• a stackoverflow post with useful links & suggestions
• about rulesets on github docs
• creating rulesets for a repository on github docs
• rulesets vs branch protection rules on github docs
• using fnmatch syntax on github docs
• fnmatch syntax on the official ruby docs