>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #1451668. --> Reported by: [webchick](https://www.drupal.org/user/24967) >>> <p>So we've had Git deployed for about a year now, but largely still use conventional patch-based workflows when it comes to collaborating (particularly in core). There are a few brave trailblazers who are trying to use a more Github-like approach, where they do work off in a sandbox project away from the main queue until they have something worth looking at. The problem with that is the lack of visibility among other collaborators within the "parent" project, and this has been especially problematic in cases like <a href="http://drupal.org/node/683026">Bartik</a> (in which there were forks of forks of forks and no clear delineation as to whose fork had the latest stuff in it) and <a href="http://drupal.org/sandbox/Crell/1260830">WSCCI</a> (which is attempting to re-write large swaths of core without the benefit of large swaths of core developers who understand the subsystems they're touching having any idea what's going on).</p> <p>However, it's pretty clear that in order to scale the community and our ability to collaborate with one another as we grow to our next 700K users, we <em>really</em> need to figure out how we can best use the distributed workflow that Git allows us, so that people can work "off the grid" until there's something to show, but core generalists/committers can keep an eye on things coming down the pipe before they're blasted in the face with an unreviewable 500K+ patch.</p> <p>Mark Sonnabaum and I had a discussion tonight in #drupal-contribute about how we might better integrate sandboxes with their parent projects. Here's my interpretation on how this might work, encompassed with some late-night omnigraffling/skitching.</p> <h2>Show sandboxes on projects</h2> <p>We add a node reference field on projects that associates them with their "parent" projects, and then keep track of sandboxes for a given project on a tab. And of course, you could make sandboxes of sandboxes if you wanted to, since they're also just projects. (Normally, though, you'd just add more maintainers to the canonical sandbox).</p> <p>This is basically what you do when you're kind of still figuring things out and shooting wild and crazy code around that people don't really need to look at yet.<br> <img src="https://drupal.org/files/issues/20120223-kcxwndg8jr3mfhc8jmdakefej.png" alt="20120223-kcxwndg8jr3mfhc8jmdakefej"><br> <img src="https://drupal.org/files/issues/20120223-tdktr4bc6qhg7wg6jn48mw32pk.png" alt="20120223-tdktr4bc6qhg7wg6jn48mw32pk"></p> <h2>Have a view for associated sandbox issues</h2> <p>People like Dries, catch, sun, xjm, David_Rothstein, me, etc. who need to keep abreast of major happenings across <em>all</em> of core cannot realistically follow 300+ separate sandboxes. So for us, there's an alternate view of the core queue that pulls in issues from sandboxes with a node-reference to the current project.</p> <p><img src="https://drupal.org/files/issues/20120223-knwtakruy99d64eq8bcw1e8ei6.png" alt="20120223-knwtakruy99d64eq8bcw1e8ei6"><br> <img src="https://drupal.org/files/issues/20120223-mt69sdpr68t8ctqa14tybhsfg5.png" alt="20120223-mt69sdpr68t8ctqa14tybhsfg5"></p> <h2>Pull requests</h2> <p>As a sandbox developer, once you get to a certain point you actually want to promote your work to the parent project's attention. This works by specifying a certain branch of code to promote to the parent project, then basically gives you a project add form, same as before. Except now, you can associate issues with one or more sandbox projects. If you do, then commits to those sandbox projects show up inline along with the comments on the issue.</p> <p><img src="https://drupal.org/files/issues/20120223-b2n1i2564tu8gf1uxt97h1s75q.png" alt="20120223-b2n1i2564tu8gf1uxt97h1s75q"><br> <img src="https://drupal.org/files/issues/20120223-ftqu3pwmupb15bfx8fq1t2y8mm.png" alt="20120223-ftqu3pwmupb15bfx8fq1t2y8mm"><br> <img src="https://drupal.org/files/issues/20120223-kmpfw3uqmkwbuik65t755uee6j.png" alt="20120223-kmpfw3uqmkwbuik65t755uee6j"></p> <h2>Wherefore art thou, per-issue repos?</h2> <p>Back when the Git work was first being specced out, we had talked about doing <a href="http://groups.drupal.org/node/50438">per-issue repositories</a> to preserve the "swarm" effect that our community does via collaborating together on issues. However:</p> <p>a) This is a completely new and untested idea, not yet proven in the wild anywhere<br> b) Which means it's a Drupalism, and one of the big reasons we moved to Git was so people could use standard tools<br> c) The sandbox method is proven by Github, and since sandboxes allow multiple maintainers, it provides for "swarming"/collaboration.<br> d) The biggest reason for per-issue repos is for "one spot to check", but if we pull in commits from related sandbox, that accomplishes the same thing.</p> <p>That's my spiel. :) Thoughts?</p>