Если речь об организации работы с кодом открытого проекта, то:

1. Да, было бы разделение зон ответственности. И это касается не только кода. Документация, администрирование форума и сайта, администрирование багтрекера, тестирование - проект состоит не только из одного написания кода. Наверное даже написание кода составляет меньшую часть проекта.

2. Организовано бы это было путем публикации списка зон ответственности и ответственных за них участников проекта. Постоянная поддержка данного списка в актуальном состоянии - это тоже зона ответственности кого-то из участников. Список составляется на основании добровольно взятых на себя обязательств. Участники проекта сознательно и добровольно соглашаются не вмешиваться в чужие зоны ответственности даже при наличии технической возможности для такого вмешательства.

3. Методика принятия заявок и внесения коммитов - это по большому счету личное дело ответственного за участок работы. Как лично ему удобно - так пусть и принимает заявки и вносит коммиты. Более того, данные методики будут сильно зависеть от того ПО, которое используется в проекте для учета заявок и для контроля над версиями.
При работе с CVS и с багзиллой лично мне очень нравится технология работы, принятая в команде Багзиллы (почитать подробнее можно тут: http://www.1cpp.ru/forum/YaBB.pl?num=1204133873).

4. Политика принятия решений по спорным вопросам - это более субъективное понятие. Есть как минимум два варианта, которые мне кажутся допустимыми.
а) В проекте должен быть человек, за которым всегда остается последнее слово.
б) Принимаются ЛЮБЫЕ разумные предложения до тех пор, пока принимаемые предложения не начинают противоречить друг другу. В такой ситуации не принимается никакого решения до тех пор, пока спорящие стороны не договорятся о единстве мнения, или пока одной из сторон не надоест спорить.

Коммерческие проекты тоже бывают разные.
Бывает работа в офисе на одну компанию, а бывает разработка тиражного продукта.

Работа в офисе на одну компанию гораздо проще в плане организации. Все толпой коммитят, в случае чего подошел и пообщался лично.
А с работой над тиражным продуктом я не сталкивался, так что ничего не скажу. Тут лучше седмина пытать. Хотя я не знаю, насколько у него там коллективно идет работа.

fez писал(а) 06. Марта 2008 :: 07:58:

Я тоже 5 лет назад так думал. Махнул рублем - и все само собой организовалось.
Сейчас, думаю, в условиях дефицита кадров, все сложнее.

Ты своих людей как удерживаешь, чтобы не свалили? Ладно, не отвечай, я догадываюсь.

P.S.
Начальника тюрьмы спрашивают:
- Почему у вас заключенные даже не предпринимают попыток к бегству?
- А я им каждый день читаю выдержки из утренних газет...

kms писал(а) 06. Марта 2008 :: 08:06:

Для меня это было очевидным с самого начала.

fez писал(а) 06. Марта 2008 :: 08:51:

Потому что предмет сложен. Мало кто может чего сказать толком и правильно и не сесть в лужу.
Даже если и изучал менеджмент в институте, то практически применить/закрепить было негде...

artbear писал(а) 06. Марта 2008 :: 09:23:


Вот эта вот механика, как мне кажется, позволяет решить две существующие проблемы. Первую проблему описал ты сам чуть ниже, про оперативность внесения исправлений и дополнений. А вторая проблема - это основая претензия kms'а к тебе. Внесение некачественного кода и потеря контроля над кодом со стороны ответственного за этот код.


artbear писал(а) 06. Марта 2008 :: 09:23:


Вот тут есть еще и другая данность. Любой разработчик хочет сохранить контроль над своим участком кода. Это на самом деле очень важно. И твой вариант никак эту проблему не может решить, он даже наоборот, ее усугубляет.

artbear писал(а) 06. Марта 2008 :: 09:23:


Совместное владение кодом хорошо работает в рамках XP. Когда применяется парное программирование. В любом случае совместного владения кодом без общения не получится. В рамках твоего предложения вот это самое общение вообще ничем не обеспечивается.

fez писал(а) 06. Марта 2008 :: 10:40:

Федор, мои 100% означает, что я лично согласен на 100% и больше ничего.
По остальному почитаю и выскажусь.