В какой-то базе писать все внесенные изменения. Кто, что, зачем, когда... В формате: "было-стало-а зачем?-кто делал". Это сильно упростит дальнейшую поддержку даже в случае отсутствия основного разработчика.
Я сторонник попробовать сделать все через стандартные возможности ядра Друпала и "зелеными" модулями (см. статью "Веб-программирование, 7 ступенек в рай"). Это будет демонстрацией клиентам, что "зеленое" построение сайта возможно.
Для "зеленого" решения журнал развития проекта можно вместо базы хранить в ноде (материале) подходящего типа. При работе в паре ноду должны иметь возможность править оба. В будущем когда старый мастер уйдет с проекта, другой мастер должен иметь возможность править журнал. Давать всем мастерам модераторские права на правку опасно.
Самых подходящим мне представляется использование модуля book. Он обеспечивает групповую работу над документом. И в то же время страхует от резких телодвижений одного из разработчиков с помощью системы версий. Конечно, в book откаты делаются сложнее, чем в вики, но к ведению журналов будут иметь доступ только свои мастера, так что book видится жизнеспособным решением.
На каждый проект можно заводить отдельный book, который будет состоять из стандартных страниц:
- общая информация по сайту (URL, клиент, фамилии ответственных за проект 2-х мастеров, версия Друпала,...)
- список установленных модулей и их версий
- список заведенных нестандартных корневых папок с пояснениями
- список скриптов в нодах, хаков, самописных модулей и прочих нестатических решений
- обнаруженные глюки
- to do
- ...
Информация по каждому проекту будет открыта для Гостей и клиентов. Менять book могут только мастера, у них у всех назначены права на изменение. Но реально изменять журнал проекта будут только мастера, отвечающие за проект.
Так, с персоналиями прояснили, теперь предложения по делу: есть скрипты для групповой работы над проектами. Вот этот попробуйте: http://www.dotproject.net/.
Упс. Если мы с первого дня начнем наращивать свой сайт движками, то получается грош цена Друпалу.
Хорошо бы попробовать обойтись только штатными средствами Друпала. Пусть будет не так удобно, но зато:
- найдем подходящее "зеленое" решение для групповой работы над проектами
- покажем клиентам, что можно жить под чистым Друпалом без других движков
- сможем обновлять сайты за полчаса
- ...
Зачем это нужно: все работы по проектам должны не в аськах и мылах болтаться, что потом концов не сыщешь: кто что просил, кто что обещал, кто там чего не понял..., а быть в БД. Там должно происходить все деловое общение.
Вариант замены базы я предложил выше.
..........................
Макс Кириленко, подбор названий и доменов
Я, в целом, за
Автор: Вадим Барсуков
Я, в целом, за принцип - "все делаем средствами Drupal". В частности, есть модуль project, который - кажется - реализует идею совместного ведения проектов.
Но - без фанатизма. Поскольку эффективность - важнее "понтов". :) Если окажется, что для производительной работы сообщества что-то нужно и этого нет в Drupal, надо будет пользоваться этим внешним "чем-то" без зазрения совести. Но вести планомерные работы по созданию друпальского аналога (опять же, если это нужно - Drupal не должен и не может заменять все).
В этой связи - вероятно, мастерам понадобятся т.н. "внутренние проекты", которые не являются непосредственно коммерческими, но в них заинтересовано все сообщество мастеров. Например, разработка каких-то модулей для общего пользования, тем оформления, дополнительного инструментария (скажем, xmlrpc-клиент для блоггинга и администрирования сайтов) и др. Возможно, такие проекты нужно будет создавать через стандартизированную процедуру "внутреннего заказа" (тендер, конкурс, гранты?) и оплачивать работу из "общака" мастеров (хм, "казны" мастеров...).
Внутренние заказы
Автор: Макс К.
vadbars says: Возможно, такие проекты нужно будет создавать через стандартизированную процедуру "внутреннего заказа" (тендер, конкурс, гранты?) и оплачивать работу из "общака" мастеров (хм, "казны" мастеров...).
С финансирование без проблем.
Если будут еще какие-то идеи по использованию для развития студии вторых 50%, (которая "казна") тоже пишите. Деньги собираю с мастеров не для того, чтобы их копить. Часть проем, часть пущу на рекламу, а остальное можно вложить во внутренние дела студии.
Например, как только накопится достаточная сумма, нужно будет заказать нормальный дизайн. Что бы мы там не говорили о преимуществах Друпала, клиенты подсознательно будут оценивать его по дизайну сайта. Надеюсь, что деньги на дизайн останутся внутри студии и заказ сделает кто-нибудь из своих мастеров. Ему заодно и лишняя ссылка будет на образец работы.
..........................
Макс Кириленко, подбор названий и доменов
Тут ведь вот какое дело...
Автор: Александр из Москвы
Внутренние возможности - ну нехай будут внутренние. Просто тот движок как раз таки заточен под удаленную командную работу. Там удобно проводить тендеры, писать групповые письма участникам команды и т.п. Я уже забыл подробности, благо давно не просматривал.
Как верно подмечено, не надо фанатизма "все на Друпале и только". Клиенту вполне по задачам может Джумула оказаться - зачем его тянуть на друпал? Ставится она за 5 минут, требования к хостингу минимальные... Только надо предупредить, что если надумает расширять функционал - его ждут такие-то и такие-то чудеса с поисковиками, оплата нового сайта и конвертация базы.
Доступа гостей не надо. Даже не надо доступа зарегистрированным. Это внутренняя кухня, нехрен всем знать подробности.
А кто будет это вести? Кто контролировать? Наверняка значительная часть мастеров на это благополучно забьет. Или напишет что-то формальное "сделан сайт Пупкин и партнеры".
..........................
http://cwll.biz - Персональный блог на Друпале