Rewrite Site Builder's Guide

Just a couple of notes here:

I'm assigning this to myself as I think I should, since I've volunteered myself to work on this documentation.

I've read and heard a few different proposals for a canonical Git methodology, but I'm personally a bit concerned that if the basic process for using Git in this context is too weighty, nobody will want to use it, which I think would be a shame. As I have said, there are a lot of ways to employ Git in the processes of building and deploying Drupal sites, but I feel that it's essential to get the basics down for the people that haven't yet found their own personal methodology.

More and more, I'm feeling that the approach for this guide should be a distillation of best practices in this context, with additional documentation / subpages that explore specific working models. Perhaps a document with some basic guidelines and a basic KISS model of site development supplemented with additional process documentation for larger teams/more complex models/etc.

Thanks for that. Dog looks like it goes a long way towards mitigating some of my personal concerns about advocating for a fullly Git-managed project (i.e. branching from a checkout of core, submodules for contrib modules, etc) to beginners, but I'm still torn about whether the guidebook should advocate additional tooling and complexity as a first-level/getting-started step.

I'd love to have some discussion about this topic largely because I can't decide which is the best approach: should the main Site Builder's Guide outline a basic approach to integrating Git into this workflow, with subpages outlining the benefits and procedures of cloning Core, using submodules and leveraging additional tools like Drush/Dog or should the 'best practice' be outlined in full, even if it's fairly complicated?

I have updated http://drupal.org/node/803746 with a first draft of the rewrite. I think it provides insight into best practices while staying straightforward for those who are new to Git. I recognize that it's not all things for everyone, and some supplemental documentation needs to be written to cover some more advanced topics, but I think it's definitely a start. Feedback welcome, of course.