Процесс

1. Система бранчей: qreal/master — интеграционная ветка. Для каждого релиза, если его не удаётся выпустить до перекладывания в master новой функциональности, отводится релизная ветка, в которую новая функциональность не попадает. Релизные ветки интегрируются в ветку release. Крупные куски новой функциональности, требующие участия нескольких человек, разрабатываются в feature-ветках внутри основного репозитория и реинтегрируются в master на правах девелоперских веток. Подробнее см. http://scottchacon.com/2011/08/31/github-flow.html и http://nvie.com/posts/a-successful-git-branching-model/.
2. Перекладывание любой функциональности в master возможно только после ревью. Ревьюить может кто угодно из списка контрибуторов, кроме авторов коммитов. Это касается всех.
3. Разработку можно вести либо в своём форке, либо в feature-бранче (предпочтительно). По окончании — делать pull request (github позволяет делать pull-request’ы даже между ветками одного репозитория).
4. Условие перекладывания. Должны быть выполнены все правила Стайлгайда (даже те, о которых не помнят те, кто его писал), написана документация к каждому классу и к каждому public-методу класса. Желательно, чтобы была документация и к неpublic, и к реализации. Также должен быть выполнен merge с веткой, в которую оформляется pull-request (во избежание продолжительного разрешения конфликтов при обработке pull-request’а). См. также пп. 5 и 6.
5. Каждый крупный кусок функциональности должен иметь страничку на вики, рассказывающую, как он работает и как устроен, по примеру http://tinyurl.com/4xv6dcb. Она должна там появляться одновременно с перекладыванием в master, если нет, пулл-реквест не принимается. Что такое “крупный кусок функциональности”, в каждом случае решается отдельно.
6. Помимо указанного в п. 5, для любой законченной функциональности, видимой пользователю, должна быть страничка на вики, рассказывающая, как ей пользоваться (даже если функциональность по размеру небольшая, типа излома линков). Описание должно быть достаточно подробно, чтобы потом можно было это вставить в документацию. Также должен прилагаться план тестирования, чтобы потом можно было убедиться, что функциональность не поломалась.
7. Обо всех изменениях в коде или документации, которые могут коснуться всех, надо отписываться в рассылке. На рассылку должны быть подписаны все, кто должен править или хотя бы смотреть код QReal.
8. За все проблемы, найденные в ветке master, несет ответственность ревьюер соответствующего коммита.
9. Непереложенная в master функциональность официально не существует, защищать по ней курсовую, диплом или диссертацию нельзя.
10. Панические хаки в ночь перед показом делать в своих ветках, но с учётом пп. 9 и 2.