The actual documentation for contributing to Quickstart is kept close to the source in the README of the Bitbucket Repository. That way, as the details inevitably change, they are very easy to keep up to date.
However, if you are curious about some of the development philosophies that guide the evolution of Quickstart, you can find that here.
Web developers at the University of Arizona share a lot of common challenges. UA Quickstart is a shared solution. If every site you build is a special snowflake, it's often not worth the effort to clean up the long tail of web development: cross browser support, accessibility, responsiveness, security, etc. If all of the big problems are already solved for you and you run in to a small problem, you can fix it once and positively impact hundreds of sites on campus.
This can jump start your web project, decrease delivery time, and replace technical implementation decisions with decisions that will drive enrollment, advancement, research/partner support, faculty recruitment, and other institutional goals.
UA QuickStart has a single source repository for the project that all improvements or fixes are made to. Everything about Quickstart is kept in code, even things that are often otherwise stored in a database: Configuration, Views, even Demo Content. This allows us to keep everything version controlled so that we can handle merge conflicts and have a history of everything that gets merged.
Developing locally allows for faster and lower risk development. Your website shouldn't be a Frankenstein of experiments. This workflow enforces doing all of that in your local workspace and only pushing up the code that works.
Well Documented Workflow
When you've got a well documented workflow more people can contribute to the project. With the step by step instructions provided in the documentation, Arizona Digital has had contributions from developers with all different levels of experience, site builders, designers, and even business analysts. Everyone using Quickstart will be bringing their own perspective to the overall project, and sometimes something that would be acceptable for a developer is completely unusable to a site builder. While there is a normal backlog of work for developers to eventually get to, anyone that is willing to learn something new can follow the instructions and submit their first Pull Request. The easiest way to predict the future is to build it yourself!
The main repo is always ready to deploy as a working copy of Quickstart and includes any changes or updates, whether big or small, within minutes of being merged. Every Pull Request triggers a complete build of Quickstart on our build server that must pass a series of tests. Once built, the code can easily be tested by stakeholders with many different priorities: security, code quality, accessibility, design, usability, and brand standards. Because the build process is automatic, it is very easy for many non-developers to review updates quickly.
Within any framework, there can be many different ways to accomplish the same thing with different trade offs between security, performance, readability, usability and maintainability. Code review brings these trade offs to light.
We all make mistakes. Code review allows us to catch them.
Code review can be intimidating, but allows every developer to grow and learn from each other.
Code review can be slower than just shipping in the short term, but allows teams to move faster in the medium and long terms due to fewer bugs and less technical debt.