>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #2488266. --> Reported by: [tvn](https://www.drupal.org/user/999848) >>> <p><em>This issue is a summary of research done by the Drupal Association staff, and based on various conversations, which happened in the Drupal community over the years. This was presented in more detail at <a href="https://events.drupal.org/losangeles2015/sessions/issue-workspaces-better-way-collaborate-drupalorg-issue-queues">DrupalCon Los Angeles</a>.</em></p> <h2>Background</h2> <p>Current issue queue workflow while works, has its limitations:</p> <ul> <li>Complex workflow with many steps</li> <li>Trivial changes require complex workflow</li> <li>Difficult for Learners</li> <li>No visibility between issues</li> <li>Patch Review can be challenging</li> <li>Stale Patches</li> </ul> <p><strong>A better issue queue:</strong></p> <ul> <li>Uses git, instead of patches to submit, review and accept work (e.g. "Pull requests", "Forks")</li> <li>Detects code conflicts and provides immediate notification</li> <li>Integrates code review functionality</li> <li>Allows inline editing for smaller fixes</li> </ul> <p>We want to build that better issue queue, while meeting the following constraints:</p> <ul> <li>Minimize disruption</li> <li>Preserve collaboration</li> <li>Keep Drupal.org home of the community</li> <li>Limited resources</li> </ul> <h2>Possible solutions</h2> <ol> <li>Do nothing :)</li> <li>Migrate to externally hosted solution (GitHub, BitBucket, Gitlab.com)</li> <li>Use self hosted solution (Gitlab/Phabricator, Diffy, FishEye / Crucible)</li> <li>Modernize Drupal.org's Issue queues</li> </ol> <h3>1. Do nothing</h3> <p>Is not really an option. We repeatedly hear from users, that they need better tools.</p> <h3>2. Move to a hosted service</h3> <p>Examples of hosted services: GitHub, Bitbucket, Gitlab.com, etc.</p> <p><strong>Moving to GitHub</strong><br> GitHub came up in discussions again and again. While being a great site in itself, there is one fundamental difference, which makes the move to GitHub at the very least problematic, if not dangerous for our community.</p> <p>The fundamental difference is in the data model or coding workflow.</p> <p>GitHub's Data Model: Fragmented Social Coding</p> <ul> <li>Code changes on GitHub are pull requests.</li> <li>Both pull requests and issues have comments.</li> <li>If someone else wants to work on the same code, they fork a pull request.</li> <li>When you fork a pull request, you fork a conversation. It is now in multiple places.</li> </ul> <p>Drupal.org's Data Model: Collaborative Social Coding</p> <ul> <li>Code changes on Drupal.org are patches.</li> <li>Patches live in comments on issues</li> <li>If someone else wants to work on the same code, they create a new patch.</li> <li>Conversation happens in one place.</li> </ul> <p>GitHub would give us pull requests, code conflict detection and immediate notification, integrated code review functionality, inline editing for smaller fixes. However:</p> <ul> <li>The move would be very disruptive, especially at this stage of Drupal 8 release cycle.</li> <li>It breaks the model of collaborative coding, which is the basis of the Drupal community.</li> <li>Drupal.org would no longer be the place where everyone goes for code.</li> <li>Limited Resources - This solution is sometimes perceived as the most efficient and easy, however building integration between the current site and GitHub is a non trivial project, which won&rsquo;t be much easier than some of the other options.</li> <li> </ul> <h3>3. Move to self-hosted tool</h3> <p>Examples of self-hosted tools: Phabricator, Gerritt, Gitlab, Fisheye, Crucible, Diffy.</p> <p>Self-hosted tools have a few advantages over moving to a hosted service:</p> <ul> <li>Data models might not be as different, so we could potentially keep the collaborative model we currently have. </li> <li>Drupal.org would still be the central place of everything Drupal.</li> <li>Self hosted means we own the data.</li> </ul> <p>However, switching to a new tool would be a massively disruptive change. Resource requirements are even more complex, because of the need to host the solution ourselves. We&rsquo;d have additional maintenance and security burdens.</p> <h3>4. Modernize Drupal.org issue queue</h3> <p>This one is not a new idea as well. There were various plans and ideas how to modernize our issue queues before.<br> We have 4 years worth of ideas &amp; suggestions to draw from.</p> <p>We can switch to using git, instead of patches to submit, review, and accept work, code conflict detection and immediate notification, code review functionality, inline editing for smaller fixes.</p> <p>And this options meets all of our constraints:<br> 1. Minimal Disruption + Preserves Collaboration:<br> - we&rsquo;ll have minimal disruption, because we are not making people learn anything new, we are improving what we have;<br> - our model of collaborative coding won&rsquo;t change;<br> 2. We&rsquo;ll keep Drupal.org home of the community<br> 3. Limited Resources: This will be a big undertaking, however right now we are positioned much better to make it a success than even 1 year ago. The specific solution we&rsquo;d like to propose is not something completely new we&rsquo;ll be building from scratch, essentially we&rsquo;ll be using a new feature in Git, already built.</p> <h2>Proposed resolution</h2> <p><strong>Shared forks in Drupal.org&rsquo;s GitLab instance for collaboration</strong></p> <p>Forks of projects in GitLab are <a href="https://about.gitlab.com/2019/07/22/gitlab-12-1-released/#git-object-deduplication">now relatively cheap</a>, and getting better.</p> <ul> <li>One fork per issue.</li> <li>Any number of shared branches for working on resolving the issue. Some or all may be protected later, <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-3"><a href="https://www.drupal.org/project/drupalorg/issues/3070177" title="Status: Closed (duplicate)">#3070177: Protected (per-user?) branches in issue workspace forks</a></span></li> <li>A branch pointer to the &ldquo;Latest&rdquo; so users can easily pull in the most recent change into their own branch.</li> </ul> <p><strong>How would the new Git-based workflow work</strong></p> <ul> <li>When a user wants to work on an issue, they will see instructions to clone the issue&rsquo;s fork e.g.:<br> <code>git clone --branch &hellip; git@git.drupal.org:project/drupal/issues/123456.git</code></li> <li>User makes their changes</li> <li>Instead of extracting and uploading a patch, they commit and push commits to a branch.</li> <li>On Drupal.org a comment will be generated on behalf of the user, that contains their commit messages. Testbots will take the changeset that was pushed and run tests on it.</li> <li>If user needs to add additional explanation of their work beyond the commit messages, they can add a comment.</li> </ul> <p>Real life example from <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupal/issues/1740492" title="Status: Closed (fixed)">#1740492: Implement a default entity views data handler</a></span><br> <img src="https://www.drupal.org/files/issues/workflow-example.png"></p> <p><strong>Legacy patch based workflow does not go away</strong></p> <ul> <li>Users can still upload patches, download and apply patches, and current tools like dredditor should still work, except no interdiff will be necessary.</li> <li>All changes via the new git workflow will also be downloadable as a patch, so this workflow will not change.</li> <li>When a user submits a patch, a commit will be created on that users personal branch so that other git using developers can work with those changes in git.</li> </ul> <p><strong>Additional features</strong><br> As an additional feature, we would like to add the ability to make commits for the issue in their browser, eliminating cumbersome workflows for straightforward edits such as code style, documentation, typo fixing etc. GitLab offers inline editing and a web IDE to make commits.</p> <p><strong>Code review in issue workspaces</strong></p> <ul> <li>As a result of preserving our legacy interface with patches, we can continue to leverage tools such as Dreditor without needing to implement code review and inline diffs as part of the MVP.</li> <li>Additionally we can provide an option to compare any two changes in the issue, providing interdiff functionality.</li> <li>Reviewing major changes does not mean a 300k patch, it can mean reviewing multiple small commits.</li> </ul> <p><strong>Merging changes upstream</strong></p> <ul> <li>Button on interface to &ldquo;squash merge&rdquo; all the commits into a single unit of work, for core probably, or even a straight merge.</li> <li>A maintainer could merge in any branch into their production codebase without squashing too.</li> </ul> <p><strong>Velocity acceleration</strong></p> <ul> <li>Reveals issues conflicts using Git</li> <li>Reduces need for &ldquo;disruptive patch windows&rdquo;</li> <li>Commits that break other changes notify immediately</li> <li>Needs Review is meaningful.</li> </ul> <h2>History, previous discussions:</h2> <p>A comprehensive summary of Github vs Drupal vs Gitlab : <a href="https://groups.drupal.org/node/313068#comment-955593">https://groups.drupal.org/node/313068#comment-955593</a><br> Github/Gitlab/Drupal spreadsheet: <a href="http://bit.ly/1tPt3qS">http://bit.ly/1tPt3qS</a><br> Git Phase Next: The Promised Land. Slides:<a href="http://bit.ly/1qKecLI">http://bit.ly/1qKecLI</a> Presentation: <a href="http://bit.ly/1AGiEfI">http://bit.ly/1AGiEfI</a><br> <a href="https://www.drupal.org/community-initiatives/git/phase-3">https://www.drupal.org/community-initiatives/git/phase-3</a><br> Implementing per issue repos: <a href="https://groups.drupal.org/node/50438">https://groups.drupal.org/node/50438</a><br> <a href="https://www.drupal.org/node/2213153">https://www.drupal.org/node/2213153</a><br> <a href="https://www.drupal.org/project/issues/search?issue_tags=git%20phase%203">https://www.drupal.org/project/issues/search?issue_tags=git%20phase%203</a><br> <a href="https://www.drupal.org/documentation/git/faq">https://www.drupal.org/documentation/git/faq</a> -&rsquo;what about pull requests&rsquo;</p> > Related issue: [Issue #2623118](https://www.drupal.org/node/2623118)