GitLab settings wording restrictive vs permissive are inconsistent
The Problem
GitLab settings use verbiage like "restrict" or "allow" inconsistently. Examples:
- Prevent sharing a project within $namespace with other groups
- Allow project access token creation
- Disable group mentions
- Allow project access token creation
- Prevent forking outside of the group
- Allow users to request access (if visibility is public or internal)
At first glance, many of these could be flipped and keep the same meaning. Example: Allow sharing a project within $namespace with other groups. But it's not clear if the language use is intentional.
When considering default checkbox states, some settings will be defaulted to checked, and some will be defaulted to unchecked depending on whether the verbiage is restricting or permissive.
See relevant thread here: #217623 (comment 587286929)
Solution
We should explore whether consistent verbiage is appropriate and if so, whether GitLab should default to restrictive language or permissive language.
One consideration if a change is made is that users' settings would change (a checked box using "prevent" would now be an unchecked box using "allow") which could be a big/confusing change for users, especially if they skim over the text and don't realize the change was made, but see their settings look "messed up."