Review internal users docs

- Move doc to dev/
- Reorg doc content
- Add "user types" to user/index.md
- Link from user/index.md

doc/administration/index.md

 ---
 stage: none
 group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers"
 description: 'Learn how to install, configure, update, and maintain your GitLab instance.'
 ---
 

doc/development/internal_users.md

+---
+description: "Internal users documentation."
+type: concepts, reference, dev
+stage: none
+group: Development
+info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments-to-development-guidelines"
+---
+
+# Internal users
+
+GitLab uses internal users (sometimes referred to as "bots") to perform
+actions or functions that cannot be attributed to a regular user.
+
+These users are created programatically throughout the codebase itself when
+necessary, and do not count towards a license limit.
+
+They are used when a traditional user account would not be applicable, for
+example when generating alerts or automatic review feedback.
+
+Technically, an internal user is a type of user, but they have reduced access
+and a very specific purpose. They cannot be used for regular user actions,
+such as authentication or API requests.
+
+They have email addresses and names which can be attributed to any actions
+they perform.
+
+For example, when we [migrated](https://gitlab.com/gitlab-org/gitlab/-/issues/216120)
+GitLab Snippets to [Versioned Snippets](../user/snippets.md#versioned-snippets)
+in GitLab 13.0, we used an internal user to attribute the authorship of
+snippets to itself when a snippet's author wasn't available for creating
+repository commits, such as when the user has been disabled, so the Migration
+Bot was used instead.
+
+For this bot:
+
+- The name was set to `GitLab Migration Bot`.
+- The email was set to `noreply+gitlab-migration-bot@{instance host}`.
+
+Other examples of internal users:
+
+- [Alert Bot](../operations/metrics/alerts.md#trigger-actions-from-alerts)
+- [Ghost User](../user/profile/account/delete_account.md#associated-records)
+- [Support Bot](../user/project/service_desk.md#support-bot-user)
+- Visual Review Bot

doc/user/index.md

@@ -72,6 +72,17 @@ With GitLab Enterprise Edition, you can also:
 
 You can also [integrate](project/integrations/overview.md) GitLab with numerous third-party applications, such as Mattermost, Microsoft Teams, HipChat, Trello, Slack, Bamboo CI, Jira, and a lot more.
 
+## User types
+
+There are several types of users in GitLab:
+
+- Regular users and GitLab.com users. <!-- Note: further description TBA -->
+- [Groups](group/index.md) of users.
+- GitLab [admin area](admin_area/index.md) user.
+- [GitLab Administrator](../administration/index.md) with full access to
+  self-managed instances' features and settings.
+- [Internal users](../development/internal_users.md).
+
 ## Projects
 
 In GitLab, you can create [projects](project/index.md) to host