Document use of groups with no functionality that can be used as teams

From discussion in https://gitlab.slack.com/archives/C1BBL1V3K/p1510614586000316.

https://help.github.com/articles/organizing-members-into-teams is nice to “map” the organization hierarchy and give permission based on teams rater than manually controlling it per user per project. It’s not always the case that a team maps 1:1 to a group/subgroup, which is the way we have to control permissions accross multiple projects that should have the same “user x permission”.

ex: Team 1 can be part of group A and B but not C, while team 2 is part of C an B. With GitLab you need to spread the control of the permissions across the 3 groups and manually add/remove users from more than one group if they change teams or are hired etc.

You can create groups to represent teams, without any projects. But it’s not natural.

"gitlab-com" as a model of GitHub Enterprise

On GitLab.com, we have a group "gitlab-com" for all of the commercial side of the house (as opposed to gitlab-org for the open source repos). In this way we use this top-level group as what GitHub calls an "organization" or "enterprise".

All members of gitlab-com immediately get a set of permissions and projects they can access when they are added to the group (e.g. when they are hired). But there are some subgroups that are more open and some that are less open. Examples:

• customer-success serves as both a service desk for the Sales team into the Customer Success team as well as internal tools used just by the Customer Success team.
• people-ops and legal are really ONLY a service desk for employees, with restrictions that allow the People Ops and Legal teams to keep things confidential when needed.

In this same way, having a root level "group" enables some of the up and down the chain permission sharing that GitHub Teams allow. Though not fully the same, it is closer to parity.