<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=480245) </details> <!--IssueSummary end--> ### Context In issue #454522+, we introduced the `user_contributions` relation. This new relation was created to allow Direct Transfer to generate placeholder users for non-members using their name and username. This was because Direct Transfer couldn't access the user information within the exported relation files. Without this relation, the alternative would have been to make multiple API requests to the source instance to retrieve user details during records migration. However, this approach could lead to potential issues, such as migration failures due to network errors. It turns out that during the implementation of user contribution mapping in Direct Transfer, I ended up not using the `user_contributions` relation for a few reasons, which I'll outline below. Instead, I opted for a different approach that retrieves user details in batches of 100 and updates the placeholder name and username in a parallel process, which doesn't affect the main migration in case of network errors and also avoids overloading the source instance with numerous concurrent API requests. One downside of my approach is that placeholder users for non-members are initially created with a generic name and username (i.e., `Placeholder gitlab_migration source user 1` and `gitlab_migration_placeholder_user_1` , and later, they are updated by the job that is executed in parallel. Reasons for not using the `user_contributions`: 1. The new relation wouldn't be available for older GitLab instances, so an alternative solution like the one I implemented would have to be implemented anyway. So, the method I implemented works for old and new GitLab versions, which reduces maintainability. 2. The `user_contributions` relation was released behind the `importer_user_mapping` feature flag, which is still disabled. Therefore, it will not be available until we enable the `importer_user_mapping` globally. 3. `user_contributions` relation is only exported after all other relations are exported. This limitation means that placeholder users with generic names still need to be created initially, with the user details updated later when the `user_contributions` data is finally exported. Therefore, the downside mentioned above would still exist if the `user_contributions` relation was used. **More considerations** Using the approach I implemented, Direct Transfer doesn't need the `user_contributions` relation. If we decide to use it, the only advantage would be to save a few network requests, with the cost of maintaining two different approaches when getting user details. The `user_contributions` relations will still be necessary when we decide to implement the air-gapped migrations, as we won't be able to make HTTP requests to the source instance. So, perhaps we should roll out the export of the new relation even if it isn't used? ### Question? **What should we do with the `user_contributions` relations?**