png

По поводу wiki.
Заводите в репозитории папку docs и кидаете туда текстовые файлы с описанием. github умеет красиво показывать определенное форматирование.

Но есть вариант лучше, попробуйте GoogleDoc.
Можно даже корпоративный сделать со своим доменом.

плюс по сравнению с wiki
1. одновременное редактирование несколькими пользователями
2. крутая история изменений
3. крутой редакторы, разные форматы офисным данных
4. экспорт данных в разные форматы

короче, такой вариант мне очень нравится ) сам пользуюсь )

Коллеги, присоединяюсь ко всему, что сказано выше.
От себя добавлю.
unit-тесты на старый код — это бесполезное занятие, т.к. там наверняка быдло код, его качественными тестами покрыть будет крайне трудоемко. я бы сделал так.
1. на весь новые функционал писать unit-тесты. программистам дать для просвещения макконела и что-нибудь по практикам TDD, SOLID, GOF.

2. старый и новый функционал покрыть интеграционными тестами.
Если есть какие-то фоновые взаимодействия, выгрузки и прочее, это можно проверять.
Пользовательский интерфейс тоже можно тестировать автоматизированно.
см. BDD. Пусть в браузере прогоняется автоматически весь функционал сайта.

3. в качестве CI-сервера я использовал hudson. Меня вполне всё устроило.
тот же Jenkins — это его форк

4. за продакшен должен отвечать только один человек.
можно организовать это так. делаем отдельную ветку, или бранч, или вообще отдельный реп.
это как организуетесь.
в него может комитить только один человек. Этот человек делает ревью всего кода перед тем как залить его в продакшен репозиторий.
соответственно этот человек «выпивает мозги» программистам, чтобы всё так было. Ну а случись что, есть за это дело ответственный, с которого спрашивается в первую очередь.

5. на счет www-скрипта — это уж слишком, если б программистов было человек 30 и функционал выкатывался бы каждый день(или хотя бы раз в неделю разными людьми), то да, а так я думаю оно лишнее.
бывают ситуации, когда приходится делать отладку на боевом комитами и www-скриптом. Кто-нибудь из программистов обязательно так сделает…

Всё зависит от крупности приложения. если проект больше чем на 3-4 месяца, то использовать в той или иной степени приходится достаточно обширный список.
Я разве что builder-ы не использовал ни разу. А так из основных почти всё
Ихмо, они нужны для крупных библиотек.
Приходится, чтобы код не превратился в помойку…

Философия ява — как основы, причем на русском.
А далее то, что выше советовали.

>>ZF || YII || Рельсы ||?
Посмотрите в сторону Symfony2
для БД/XML маппинга Docrine 2.1
для тестинга PhpUnit/Bedhat/Mink

По идеологии очень близко к Rails. Все то, что вам понравилось в rails, возможно, вы найдете в Symfony.
Rails 3 — вообще красота. Очень советую.

ZF по сравнению с Symfony по хуже… Особенно если читать сорцы ZF. Не знаю, чего они курили, но местами просто жесть… ИХМО, не гибко, не удобно.

YII — касался косвенно пару раз, ИХМО, лучше чем ZF.

В ZF есть хорошие и удобные компоненты, например, Zend_Soap, которые сильно упрощают жизнь. Так что в сторону ZF смотреть можно, но Zend_Application, ИХМО, ужасен.

Вопрос действительно пространный. Для себя его я понял так, чтобы мне ещё изучить, чтобы стать лучше. То есть вы не знаете куда двигаться дальше.
Послужной список у вас очень приличный, вы уже большой молодец. Далее идет оттачивание навыков и опыта.
Какую нишу займете — там и развивайтесь.

Будет это .NET — платформа — замечательно.
Лично мне больше нравится java / j2ee/ j2se. Но это уже дело вкуса.

Итак, советы:

0. Купите/скачайте книгуМакконнелл Совершенный код
Эта книга просто сокровище для разработчика. Сам купил по совету преподавателя на 3-м курсе, ни разу не пожалел. До сих пор открываю, и нахожу там для себя что-то новое.

1. Проверьте правильность понимания вами принципов ООП. Принципы проектирования классов и прочее.
Знать о существовании шаблонов проектирования и их применении тоже желательно.

2. Качество знаний языка SQL поможет вам проверить этот сайт. Имеет смысл так же перечитать принципы проектирования БД. Нормальные формы и прочее.

3. Если ударитесь в Web, то знать
HTML, CSS, JS надо, нужно знать хотя бы что это и как это работает.
а так хорошо знать протокол HTTP и принципы сетевого взаимодействия.

Короче, идею вы надеюсь поняли, лучше всего копить пакет общих знаний и опыта о разработке. Такие разработчики ценились всегда дорого. С такими знаниями работается качественней и эффективней.