Draft: Dynamically create gitlab team member groups

What does this MR do and why?

Problem

In GitLab day-to-day working we frequently need to communicate with other groups/people we don't know. This is might be a challenge when you don't previously know some one in the group you need to communicate with. It's usual to open the handbook to see who's in the group you need to mention, get a name/handler to then mention (@handler) in an issues/merge requests/epics/etc.

Some groups simplified that by manually creating GitLab groups with their members to centralize the mention to the group in a single handler, like @gitlab-org/manage/import/backend or @gitlab-org/manage/engineering-managers

Proposed solution

Would be nice if we had a normalized group structure reflecting GitLab organizational groups. This way, for instance, if someone need to ping a security counter part on the access team we could intuitively use something like: @gitlab-org/manage/access/security, which is following the format: @gitlab/stage/group/subgroup.

I imagine we could use some automation to create these groups from the team.yml

So I envision something like:

• @gitlab-org/manage/import/backend -> backend engineers of manage/import group
• @gitlab-org/manage/import/frontend -> frontend engineers of manage/import group
• @gitlab-org/manage/import/security -> security counter part of manage/import group
• @gitlab-org/manage/import/ux -> ux counter part of manage/import group
• @gitlab-org/manage/import/set -> software engineer in test of manage/import group
• @gitlab-org/manage/import/em -> engineer manager of manage/import group
• @gitlab-org/manage/import/pm -> product manager of manage/import group

Maybe we could even create handlers to a more broad set of people from the same stage: (follow-up?)

• @gitlab-org/manage/em -> all engineer managers of manage stage
• @gitlab-org/manage/pm -> all product managers of manage stage

Related to: gitlab-org/quality/engineering-productivity/team#44

Expected impact & dry-runs

These are strongly recommended to assist reviewers and reduce the time to merge your change.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/tree/master/doc/scheduled#testing-policies-with-a-dry-run on how to perform dry-runs for new policies.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/reactive/best_practices.md#use-the-sandbox-to-test-new-processors on how to make sure a new processor can be tested.

Action items

• If adding environment variables for reactive processors, update config/triage-web.yaml and .gitlab/ci/triage-web.yml
• (If applicable) Add documentation to the handbook pages for Triage Operations =>
• (If applicable) Identify the affected groups and how to communicate to them:
  • /cc @person_or_group =>
  • Relevant Slack channels =>
  • Engineering week-in-review