## Consolidated Code RepositoryI personally don't think this is optimum. While, sure, it makes checking out the Framework easy, it does complicate matters.It doesn't promote isolation of the code (we've had cases where tests passed in the full stack, but didn't on an individual package because some test scaffolding bled into other tests).It makes the tests for each package longer to run (if I want to make a quick fix to Keychain, I have to wait for all the other tests to run first).It doesn't allow for incremental changes to individual packages to happen when they are needed (for example, many packages could go 2.0 right now, but it's not happening because some packages are not quite ready).My personal preference, and it's come from working in both the Composer and NPM universes, is that individual package are the point of truth, manage their own dependencies (the less the better) and their own lifecycle (some packages will get a lot of support and change a lot, some won't - so be it).In terms of being able to download the whole Framework, this can be done with Composer's create-project feature. In fact, you don't want to do that at all. You want to spin up a half-dozen examples of starter applications (command line, REST, web site, et al) that people can pull down and have a skeleton application up-and-running very quickly.
## DocumentationGiven the previous comment, I feel strongly that documentation should still live with each package.However, the intention was always so be able to build the programmers API into one site (from the DocBlocks), and also compile all of the package documentation into one master site (something like what Laravel does would be what I would aim for).The advantage of leaving the docs in the same repo as the code is that you only need one pull request to check that the documentation has been adjusted appropriately for any given code change.To put it another way, it's easy to automated collecting docs from several sources. It's not easy to automate checks that there is a PR for code (and tests), and a PR for docs. The split strategy has never, ever worked for the CMS, but having docs and code in one contributor PR has worked in the Framework for many years.