
Правила и порядок участия в разработке ВК 1с++
v1.1
Авторы:
DmitrO, dmitro@russian.ru, icq:227756553
fez, fe@alterplast.ru, icq:115635003


Должностные лица:
Руководитель проекта: DmitrO (Дмитрий Ощепков)
Администратор сайта: fez (Федор Езеев)
Корректор: x-pert (Дмитрий Юхтимовский)

1. Общая информация о проекте.
1.1 Официальный сайт проекта http://www.1cpp.ru
1.2 Разработка ведется под CVS. Сервером управляет администратор сайта.

2. Общие правила разработки
2.1 Стараться не изменять чужой код. Если это совершенно необходимо - согласовать эти изменения с автором.
2.2 Вопросы разработки, которые необходимо решать, коллегиально обсуждаются в закрытом форуме разработчиков.
Форум доступен только для участников проекта. В форуме обсуждаются любые вопросы разработки.
2.2.1. Если вы участник проекта, но доступа к форуму у вас еще нет - обратитесь к fez'у, 
указав емэйл и желательный ник на форуме.
2.3 Текущий состав участников публикуется и обновляется в форуме.
2.4 Правила оформления исходного кода.
2.4.1 В начале файла указывается имя/ник автора и как с ним связаться.

4. Правила подготовки документации
4.1 Порядок разработки: документацию на свои компоненты разрабатывает автор, направляет ее корректору
для контроля орфографических/синтаксических ошибок, логичности названий методов и свойств и т.п.,
после того, как текст согласован с корректором - документация готова к публикации и направляется
администратору сайта для публикации.
4.2 Разработка документации ведется в reSt формате. http://docutils.sourceforge.net/rst.html
4.3 Документация не должна содержать историю изменения функционала, она должна содержать наиболее полное
описание текущего функционала, т.е. той версии, на которую она составлена.
4.4 К моменту выпуска релиза должна быть заполнена история изменений для
данного релиза (файл history.txt). Каждый разработчик сам решает, что и в 
какой полноте описывать в истории изменений. Но сколь-нибудь значимые для пользователя 
изменения поведения объектов желательно отразить в истории. Новые объекты должны быть 
отмечены в истории обязательно. В историю не стоит копировать документацию, все должно 
быть изложено кратко.
4.5. Без документации релиз не выпускаем.


5. Правила выпуска релизов
5.0. Начну с определений 
5.0.1. Релиз.  
Релиз - это состояние программы, в котором реализовано некоторое ограниченное 
количество фич. Не надо пытаться запихнуть в релиз все придуманные фичи, надо что-то 
оставить для следующего релиза. Все фичи, засунутые в релиз, должны быть по возможности 
стабильными и устойчивыми. 
5.0.2. Роадмап. План, в котором написано, в каком релизе планируется выпуск той или 
иной фичи. В данный момент присутствует в виде отмашки старших лиц проекта (ДмитрО, АЛьФ).
5.0.3. Отмашка. Заключается во фразе "Ну все, хорош фичи писать, пора бы и релиз 
выпустить".
 
5.1. Собственно, процесс выпуска релиза. 
5.1.1. В какой-то момент происходит отмашка. Отмахивающий ставит тэг в репозитории. 
Если мы выпускаем релиз 2.0.2.0, то тэг будет выглядеть как z_1cpp_2-0-2-0. 
5.1.2. Вся дальнейшая работа по написанию новых фич должна вестись в главном стволе 
разработки. 
5.1.3. Вся работа по улучшению стабильности нового релиза должна вестись в ветке от 
тэга, установленного в 1.1. 
5.1.4. Следует по возможности фиксировать этапы работ по увеличению стабильности 
а) тэгами типа z_1cpp_2-0-2-1, 
б) вливаниями изменений из ветки в основной ствол. 
5.1.5. По достижении желаемой степени устойчивости релиза, дается еще одна отмашка 
выпускающему (мне). 
5.1.6. При необходимости внести в выпущенный релиз какого-нибудь маленького 
багфикса - этот багфикс вносится в ветку релиза, с установкой очередного тэга и 
вливанием изменений в основной ствол. Вносящий изменения ставит об этом в известность 
выпускающего, с тем, чтобы выпускающий при необходимости внес этот багфикс в ветки 
других релизов. 
 
5.2. Процесс работы над СОВСЕМ новым и нестабильным функционалом. 
5.2.1. Подобный процесс ДОЛЖЕН вестись в отдельной ветке. Разработчик сам ставит тэг, 
сам от тэга плодит ветку, и сам же в нее коммитит. 
5.2.2. При желании разработчика, выпускающий может собирать отдельную ночную сборку 
специально из личной ветки разработчика. 
5.2.3. При достижении хоть сколько-нибуть заметной стабильности в работе - функционал 
из ветки разработчика сливается в основной ствол и работа над этим функционалом 
продолжается в обычном режиме.

6. Как стать участником прокта.
6.1 Для того, чтобы стать участником проекта - нужно связаться с каким-либо разработчиком и
заявить о своем желании, решение будет приниматься коллегиально. Обращаю особое внимание:
для этого вовсе не обязательно быть супер_мега_крутым программистом, но для этого
необходимо принять данные правила. Порядок может быть таким: желающий принять участие в проекте
обращается к разработчику со своими идеями, разработчик ангажирует его и его идеи в форуме, и
задает вопрос: кто против? Если аргументов против ни у кого нет, руководитель проекта дает команду
администратору сайта принять его в нашу масонскую ложу :) ..да идите на хер, сами пишите этот файл..
