>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3250923. --> Reported by: [irinaz](https://www.drupal.org/user/225592) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>The core of the GitLab Acceleration initiative is unlocking our self-hosted GitLab&rsquo;s full feature set on git.drupalcode.org to provide collaboration tools that match the expectations of developers familiar with tools like GitHub.com and GitLab.com. <strong>The scope of this issue is to enable GitLab issues, and establish a fork/merge-request workflow for Drupal projects.</strong></p> <p>However, we also want to preserve Drupal&rsquo;s culture of collaboration. In the Drupal project we encourage developers to work together on issues, and strive to avoid the proliferation of many forks and work being siloed in different places.</p> <h3 id="summary-steps-reproduce">Requirements</h3> <ul> <li>People should be able to begin the collaboration process from any of the places these contribution tools allows: <ul> <li>Beginning with an issue</li> <li>Beginning with GitLab&rsquo;s WebIDE while browsing a repository</li> <li>Beginning with a fork</li> <li>Beginning with someone else's issue/fork/merge request</li> </ul> </li> <li>People should be able to collaborate on a single solution (the same fork/branch/merge request) <ul> <li>When more than one person wants to collaborate on the same solution, they should not be required to each make separate forks and separate merge requests</li> <li>People should not have to wait for a maintainer or collaborator to grant access to update an issue, propose a code change, or to perform other work toward resolving issues</li> <li>Maintainers must be able to collaborate on the merge requests to their projects (not just whether or not to merge, but the underlying fork/branch the merge is coming from)</li> </ul> </li> </ul> <h3 id="summary-preferred-resolution">Preferred Solution: Shared Issue Workspace</h3> <p>Resolved blocker: Bug in Gitlab with <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/289831"> forking into shared namespaces</a> with the Developer role.</p> <ul> <li>All users can fork a project into <a href="https://git.drupalcode.org/issue">the issue forks group</a> </li><li>GitLab issues will be enabled for the canonical projects. A migration script will be written to migrate existing issues from Drupal.org to GitLab issues <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-8"><a href="https://www.drupal.org/project/infrastructure/issues/3265096" title="Status: Needs review">#3265096: Move issues from www.drupal.org to git.drupalcode.org</a></span>. Issues will be disabled for the forks, so issues don't get lost away from the canonical project queue. </li><li>Forking and gaining access to existing forks will work similar to issue forks on Drupal.org issues. A comment will be posted to each issue on GitLab with information on contributing to forks and updating credit/attribution information </li></ul> <h3 id="summary-alternate-resolution">Alternate Solution: Personal Namespaces</h3> <ul> <li>All users will have permissions to fork a project into the issue forks their personal namespace on<br> git.drupalcode.org. GitLab&rsquo;s UI is designed for using forks - for example, if you do not have access to edit<br> a file, GitLab prompts to create a fork</li> <li> When a fork is created in a personal namespace, an automated process will grant all users on<br> git.drupalcode.org the GitLab 'Developer' role on that fork, so they can collaborate. <ul> <li>Unlike on GitLab or GitHub, these forks will be collaborative by default</li> <li>The fork owner may choose to remove that access</li> </ul> </li> <li> GitLab issues will be enabled for the canonical projects <ul> <li> A migration script will be written to migrate existing issues from Drupal.org to GitLab issues </li> <li>Metadata will be migrated into labels in GitLab.</li> </ul> </li> <li>GitLab issues will be disabled for the personal forks <ul> <li>This is to encourage users to open issues in the canonical project queue. </li> </ul> </li><li> Project pages and packaging remain on Drupal.org <ul> <li> This should help prevent a fork from being promoted as the canonical source for a Drupal project </li> <li> It also ensures we're only advertising the canonical projects to Packagist/Composer. </li> </ul> </li> </ul> <h3> Definitions</h3> <ul> <li>Canonical project - a project on Drupal.org that has releases, maintainers, a canonical GitLab project, etc.&nbsp; <ul> <li>Canonical projects are the only ones that appear on Drupal.org project listings and in the composer endpoints.&nbsp;</li> </ul> </li> <li>Group - a collection of projects in Gitlab with its own namespace <ul> <li>Groups can define common labels, permissions and other settings for the projects they contain.&nbsp;</li> <li>Canonical projects live in the 'project' namespace: git.drupalcode.org/project.&nbsp;</li> <li>Issue forks live in the 'issue' namespace: git.drupalcode.org/issue<br>These are forks of the canonical projects where contributors collaborate.</li> </ul> </li> <li>Issue forks - a fork of a project created in the Issue group on</li> </ul> <h2>Implementation</h2> <p><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/drupalorg/-/work_items/3313979" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/drupalorg/-/work_items/3313979</a></span> can be done at any point, sooner is better, to get the current Drupal.org issue workflow closer to the future workflow.</p> <p><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/infrastructure/issues/3317273" title="Status: Closed (fixed)">#3317273: Set up a Drupal.org GitLab issues bot</a></span> to handle comments commanding the bot to create an issue fork, and giving people information about how to contribute to issue forks.</p> > Related issue: [Issue #3313979](https://www.drupal.org/node/3313979)