Git instructions and workflows

I’ve been working on Drupal.org documentation and Project Git Instructions (the contextual cut-and-paste directions provided for each project) not because I’m particularly the best person for the job but because as project manager for the migration, I have a vested interest in the community’s successful transition and, more importantly, I’ve been the least busy person who also has access to the team. It’s hard to document what doesn’t exist, and the project has been moving at breakneck speed to be ready for Chicago DrupalCon.

With less than 72 hours to deployment, we’re getting a much wider range of testers and more varied feedback, highlighting Git’s extreme flexibility and the myriad ways of accomplishing things. In practice, this means that every single Git command recommended can be debated and of course, will be, but in the end no single successful path can be recommended to all the people interacting with Git on Drupal.org.

What the Git Migration Team and the folks who work on Project Git Instructions are trying to provide are paths which if followed explicitly, are most likely to lead the greatest number of users to succeed while generating the fewest support requests. It is not our goal, nor should it be, to teach Git. While every developer, patch contributor, and site builder is encouraged to learn as much or as little Git as they need and desire, we strive to create and recommend ways of using Git to support vibrant, effective collaboration on Drupal.org.

The transition for our community is enormous, and toward that end, Project Git Instructions will be continue to undergo substantial transformation until the end of the day tomorrow, Wednesday, February 23. Its target audience will be, at least for now, exclusively code contributors. People deploying sites with Git are no less important in the overall scheme of things, but it’s my stance that we care for them best by caring for the contributors first. I also think that people deploying sites via Git can be well-cared for in the Drupal.org docs. Moreoever, we have a packaging system that generates tarballs, which is still the primary mechanism by which we expect site deployers to do their work - and that workflow is unchanged.

Certainly making adjustments for plain brokenness will be accommodated, but philosophically, I believe the community is best-served by making a coordinated effort, allowing the entire community and not just early adopters to interact with it, scrutinizing the process, taking full advantage of the face-to-face opportunities at DrupalCon, and doing a comprehensive review of our recommendations in mid-to-late March.

Git instructions and the workflows won't be set in stone tomorrow or ever. They'll be able to react over time, but with the key objectives of simplicity, user success, and minimized support, coupled with not intending to teach people Git or to prescribe their behavior. I’m posting this primarily so that as all the valuable, conflicting, and honestly-appreciated suggestions for improvements come in, people have some idea what’s guiding decision-making and what the time ine for engaging conversations about best practices looks like.