Merge branch...

Merge branch 'eread/refine-and-expand-wording-on-user-contributions-and-membership-mapping-feature' into 'master' 

Refine and expand wording on user contributions and membership mapping

See merge request https://gitlab.com/gitlab-org/gitlab/-/merge_requests/169542



Merged-by: Ashraf Khamis <akhamis@gitlab.com>
Approved-by: Magdalena Frankiewicz <mfrankiewicz@gitlab.com>
Co-authored-by: Evan Read <eread@gitlab.com>

doc/user/group/import/direct_transfer_migrations.md

@@ -79,8 +79,11 @@ DETAILS:
 > - Full support for mapping inherited membership [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/458834) in GitLab 17.1.
 > - Removed from GitLab.com direct transfer migrations in GitLab 17.5 in favor of [the alternative](../../project/import/index.md#user-contribution-and-membership-mapping).
-This method of user contributions and membership mapping is for self-managed GitLab instances. For the method available
-on GitLab.com, see [User contribution and membership mapping](../../project/import/index.md#user-contribution-and-membership-mapping).
+This method of user contributions and membership mapping is available for
+GitLab self-managed without enabled feature flags.
+For information on the other method available for GitLab self-managed
+with enabled feature flags and for GitLab.com,
+see [User contribution and membership mapping](../../project/import/index.md#user-contribution-and-membership-mapping).
 Users are never created during a migration. Instead, contributions and membership of users on the source instance are
 mapped to users on the destination instance. The type of mapping of a user's membership depends on the

doc/user/project/import/index.md

@@ -84,7 +84,7 @@ difficult, but several tools exist including:
 DETAILS:
 **Tier:** Free, Premium, Ultimate
-**Offering:** GitLab.com
+**Offering:** GitLab.com, Self-managed
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/443557) to direct transfer migrations for self-managed instances in GitLab 17.4 [with flags](../../../administration/feature_flags.md) named `importer_user_mapping` and `bulk_import_importer_user_mapping`. Disabled by default.
@@ -92,8 +92,14 @@ FLAG:
 The availability of this feature is controlled by feature flags.
 For more information, see the history.
-This method of user contributions and membership mapping is enabled for GitLab.com [direct transfer migrations](../../group/import/index.md). For the method available on
-self-managed GitLab instances, see [User contributions and membership mapping](../../group/import/direct_transfer_migrations.md#user-contributions-and-membership-mapping).
+This method of user contributions and membership mapping is available for
+[direct transfer migrations](../../group/import/index.md) on:
+
+- GitLab.com
+- GitLab self-managed when two feature flags are enabled
+
+For information on the other method available for GitLab self-managed without enabled feature flags,
+see [User contributions and membership mapping](../../group/import/direct_transfer_migrations.md#user-contributions-and-membership-mapping).
 With user contribution and membership mapping, you can assign imported contributions and memberships to users on the
 destination instance after import has completed. Unlike the previous method of user contribution and membership mapping,
@@ -108,9 +114,6 @@ Each user on the destination instance that is assigned a mapping can:
   attributed to them.
 - Reject the assignment.
-This feature is an [experiment](../../../policy/experiment-beta-support.md). If you find a bug, open an issue in
-[epic 12378](https://gitlab.com/groups/gitlab-org/-/epics/12378).
-
 ### Requirements
 - You must be able to create enough users, subject to [user limits](#placeholder-user-limits).