Вопросы для обсуждения по комитету site

Для работы комитета в режиме «сопредседателей» надо решить следующие вопросы:

1. Что входит в компетенцию комитета
2. Каков принцип организации работ в комитете
3. Каков принцип принятия решений в комитете
4. Границы публичности работы комитета

Это далеко не все вопросы, которые у меня есть. Кроме того, можно просто начать, а решения принимать по-ходу. Но лучше, ИМХО, хоть о чём-то договориться.

Мои предложения по этим пунктам.

1. Пока ограничиться минимумом:
   • сайт lessi.com.ua и его подсайты, все веб-сервисы расположенные на этих сайтах,
   • сайты korm.com.ua и zooshop.com.ua, все веб-сервисы расположенные на этих сайтах,
   • все сервисы доступные в нашем хостинг-пакете от. REDO (в частности, почтовый сервер)
   • сервер находящийся на коллокейшн в дата-центре Воля
   Если эксперимент по работе через комитет себя оправдает, то компетенция комитета может быть расширена до «ИТ-инфраструктура компании в Интернет и протоколы Интернет». В частности, вопрос использования ICQ пока находится в компетенции ФИС и не переносится в комитет.

1. Работа в комитете строится по следующим принципам:
   1. Все проблемы и идеи в работе сайтов и пр. фиксируются в виде рапортов в баг-трекере
   2. Участники рабочей группы вправе брать на себя инициативу по решению отдельных вопросов из баг-трекера ни с кем не согласовывая
   3. Обновление сайтов и веб-сервисов происходит через выпуск релизов. Релиз это документ, представляющий собой список задач, который позволяет координировать работу нескольких человек в одном направлении:
      • В релизе должна быть заложена некая идея вокруг которой строится выпуск релиза
      • Эта идея формулируется сначала в виде преамбулы (текстового описания), затем в виде списка обязательных задач для релиза,
      • К идее релиза не имеют отношения исправления ошибок (но при этом они имеют высокий приоритет) и отдельные задачи (которые имеют низкий приоритет), хотя если мы делаем релиз одного сайта, то к нему скорее всего не имеют отношения ошибки другого сайта
      • В релиз могут быть заложены только задачи, решение которых уже сформулировано (как правило – в виде комментариев к рапорту в баг-трекере),
      • Все задачи релиза должны иметь ссылку на соответствующий рапорт в баг-трекере,
      • Работа над релизом продолжается до тех пор, пока не будут выполнены основные задачи релиза
      • В работе может находится только один (но не менее одного) релиз; сколько угодно релизов (но не менее одного) могут находится в обсуждении.
      Есть целый ряд случаев, когда эти принципы нам будут мешать. В частности – я не могу начать работать над релизом 1.2 (идея которого – запустить korm.com.ua), пока не закончу релиз 1.1, который сейчас «в работе». Более того, я не могу считать целью релиза 1.2 «запустить korm.com.ua», т.к. в этом направлении ещё ничего не ясно (решение для задач не сформулировано), а релиз 1.1 вот-вот закончится и я буду вынужден начинать новый релиз.
      Кроме того, не ясно где заканчивается программная работа и начинается проектная. Вариант решения: программная – работа своими силами, без привлечения дополнительных ресурсов, проектная – с привлечением дополнительных ресурсов.
      Не ясна так же роль (права и обязанности) Руководителя релиза, участников РГ.
      Документ, который описывает правила работы для комитета – site@lessi:АлгоритмРабот. В нем нет раздела связанного с п.2 – когда я его писал идеи «сопредседателей» ещё не было.
2. Предлагается принцип «согласия обоих сопредседателей». При этом не ясно, что делать, если не договорились. И является ли работа в комитете «должностной обязанностью» или «личной инициативой» – т.е. можно ли за неё спрашивать?
3. Я создавал эту рабочую группу (комитет) только ради prj.lessi.com.ua вообще и НПЖ в частности (расшифровывается, кстати, Net Project Journal – журнал проекта в сети). И мне не на кого было надеяться, кроме как на сообщество из Интернет, в частности сообщество с npj.ru. Поэтому я изначально сделал эту группу максимально открытой. Предлагаю начинать именно в таком виде. Автор отдельных сообщений и документов при этом может самостоятельно ограничить права доступа к ним. В частности это сообщение видят только сотрудники, и не увидят другие, даже если они станут участниками этой рабочей группы.

На самом деле, вопросов ещё очень много, но начинать, ИМХО, надо именно с этих. Обсуждать их можно при встрече (вроде бы так быстрее) или через комментарии (с учетом того, что вопросы спорные, и мы к ним ещё не раз вернемся «быстрее» может и не значит «лучше»)