Часть 1
Часть 2
Часть 4

1. Как дожить до midterm (mid-term evaluations deadline)?

В середине лета вас ждет очень важный отчет перед Google. Если вы его сдадите, то получите свои деньги, если нет — вылетите. Сам отчет прост — вы заполняете анкету, и ваш ментор заполняет анкету. Если ваш ментор вами доволен, т.е. он заполнил анкету — то вы получаете заветные баксы, если нет — то с вами прощаются.

Главный критерий прохождения мидтерма — предоставить обещанный код по вашему Timeline. Нет кода — нет денег. Официально Google не интересует, что именно и как вы делаете — главное, чтобы сообщество было счастливо. Если счастливо сообщество, то Google тоже счастлив. Так, чтобы дожить до отчета, нужно осчастливить сообщество.

Чтобы сообщество было счастливо — отчитывайтесь регулярно (помните то самое слово «демократия»). Если вам никто не запрещает отчитываться в рассылке — шлите отчеты туда. Если вы ведете блог, то шлите в рассылку короткие отчеты со ссылкой на полные в вашем блоге. Важно, чтобы сообщество тоже видело, что вы работаете, а не только ваш ментор. Можно забыть посетить ваш блог, но почту проверяют все.

Общайтесь с другими разработчиками. Иногда самую большую помощь вы можете получить не от своего ментора, а от другого члена сообщества. Так у одного студента были проблемы, о которых он сообщил в рассылке. Его ментор ответил, что он разочарован текущими результатами и не знает, почему код «hello world» не работает. А вот остальные разработчики приложили массы усилий, чтобы разобраться с проблемой и найти решение. Ментор в конце треда лишь разрешил последовать их советам.

Коммитьте только чистый код. Менторы очень редко просматривают каждый коммит студента. Обычно, им достаточно самого факта наличия кода и отчетов (правда, моему другу как-то попался ментор, который проверял все коммиты — но мы решили что это биоробот). Но все это до определенного времени. Бывает, что у ментора выдался свободный день и он, наконец, решил протестить ваш код, а вы именно этим утром закоммитили свой ночной труд (да, самый фантастический код пишется ночью), который просто безбожно глючит. И вот, вместо того, чтобы осчастливить сообщество своими результатами, вы подставите под сомнение всю свою работу. А если это случилось перед пресловутым мидтермом, когда ментор готов вам выставить оценки — вдвойне не хорошо. Так что создайте себе где-нибудь мусорку отдельно, а бранч оставьте для рабочего кода.

Если у вас какие-то проблемы или вы проваливаете свой deadline, то вам следует об этом сообщить как можно раньше, лучше в рассылку, чтобы к вам на помощь пришли все разработчики. Ваш ментор и сообщество не ожидают, что вы сразу начнете блистать и тащить с самых первых дней (нет, они-то конечно надеются, но прекрасно понимают, что так не бывает).

Если вы писали ваш timeline от балды, то, как только вы будете в состоянии написать жизнеспособный план — сделайте это и вышлите копию ментору. Так ему будет проще контролировать ход разработки. Чаще всего, ментор задает именно такой вопрос: «что ты сделал по своему плану и что делаешь сейчас?»

Не занимайтесь детальной проработкой мелких деталей на начальных этапах разработки. Все заказчики мыслят одинаково — сначала все хотят видеть скелет, а только потом — мясо. К мидтерму вы должны предоставить работающий прототип, а не отполированные до блеска пару функций. Пометьте дыры каментом «todo» и продолжайте разработку дальше.

2. Как пережить midterm?

За две недели до начала данного мероприятия, спросите вашего ментора, доволен ли он вашей работой и какой результат он ждет к мидтерму.

Даже если вы очень хорошо работаете и четко следуете своему плану, это не значит, что ваш ментор не имеет у себя в голове свое собственное представление о промежуточных результатах. Может, он думает, что какая-то часть точно будет работать, а вы запланировали ее тестирование только после отчета. Разница вроде неделя — но в одном случае есть рабочий код, в другом нет. Телепатия — это самый плохой метод общения. Так что лучше уточнить все заранее. За неделю до мидтерма вы точно должны знать его ответ.

Если вы не особо много описывали свой проект в рассылке, то самое время сделать это сейчас. Бывает так, что по ходу разработки и описывать нечего, особенно если проект исследовательский и вы весь месяц долбились только с одной задачей или кодили одну маленькую, но очень сложную функцию. Если раньше в вашем отчете вам нечем было хвастаться, то теперь вы можете расписать все, что сделали, добавить результаты тестирования и описание следующих шагов разработки. Помните — «демократия», «счасливы».

Ни в коем случае не коммитьте грязный код перед мидтермом в надежде показать как далеко вы продвинулись. Как раз за одну или две недели разработчики начнут интересоваться вашими результатами. И будет очень не хорошо, если ваш черновой вариант положит всю систему намертво. По той же причине не пренебрегайте тестами — ваш код не будут смотреть, его будут тестировать.

3. Разгон проекта и отчеты.

Где то недели за две или три до мидтерма настпуает разгон проекта. Т.е. с каждым коммитом все больше и больше прибавляется кода и функционала. Но творение ваше еще не в состоянии проходить нормальные тесты, так что только вы один и видите, что там уже не просто кусок глины на столе, а кувшин вырисовывается.

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

Грязные хаки 2.

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

А вот если вы кодили-кодили, а потом запустили тесты и оказалось, что немного неправильно вы что-то там сделали и очень большой кусок нуждается в доработке или переработке. И тут как раз ваш ментор хочет на код посмотреть и потестировать его. Хороший студент подумает, что не гоже ментору на такое смотреть и начнет все переписывать, а умный закоммитит так, как есть.

Во-первых, как-то ваш код все же работает и тот факт, что некоторые тесты он проходит, вас немного порадовал. Также эти результаты могут порадовать и вашего ментора, ведь он увидит что-то работающее и поверит, что вот-вот и оно совсем заработает. Во-вторых, весь ваш проект состоит из работ (был такой предмет на 4 курсе, но в то время мы как-то не прониклись данной философией). Некоторые из них критичны и их нужно выполнять последовательно, а некоторые можно сдвигать по срокам. Когда вы обнаруживаете, что что-то из критичного нужно переделать, а отчет близко, то оставьте рабочий код в покое и сосредоточьтесь на других работах. Так вы и отчет пройдете и высвободите себе время на доработку важного куска после отчета. В-третьих, если вы не затащите и ваш код не заработает как нужно (а может и хуже сделаете), то ментор может вам вообще не поверить. Ну откуда ему знать, что вы и вправду работаете, а не врете ему? Так что коммитьте, но по-умному.

Вместе с вами будут работать и другие студенты. Краем глаза поглядывайте на их прогресс и старайтесь не быть хуже их. Ментора не сделает счастливым тот факт, что его студент — самое слабое звено. И помните, что не все студенты равны. Есть студенты, которые уже часть сообщества, и они могут проводить исследования хоть всю программу, если сообществу так нужно. Но это не значит, что вам так можно.

Если у какого-то студента проблема и вы знаете, как ее решить, потому что уже столкнулись с чем то подобным — помогите ему. Во-первых, человеку поможете, а во-вторых получите +1 к коммуникабельности.

Если вас просят прислать какой-нибудь хитрый отчет, а вы не понимаете, что от вас хотят — сделайте хоть что-нибудь. Лучше вы получите стену текста из комментариев и десять раз его потом перепишете, чем будете долго и упорно молчать.

Золотое правило.

Русская техническая школа обожает телепатию. Если в вашем ВУЗе вам проще всю ночь гуглить или создать тему на всех технических форумах рунета, чем подойти к преподавателю и выслушать, какой вы идиот, что сами до всего не додумались — то тут такое не покатит. Спросите вашего ментора, если вам нужна помощь. В конце концов, они ответственны за тех, кого приручили.

4. Как юзать ментора?

Как справку к исходникам.

5. Конфликты.

Факт наличия конфликтов признают все — и Google и сообщества. Думаю, т.к. лето кодинга проводится не в первый год, то механизм разбора ситуаций уже выработан.

Если у вас есть:
1. Работающий прототип
2. Вы делали регулярно отчеты
3. Вы начали коммитить код в конце мая
4. Вы соблюдали свой план

а ваш ментор вами все равно не доволен, то вам следует обратится к сообществу. Если ваш ментор несчастлив от вашей разработки, то это не значит, что ваши результаты не понравятся другим разработчикам тоже. Вполне вероятно, что число людей «за» будет больше, чем «против». Если в вашем сообществе есть человек, который отвечает за весь GSoC, то обратитесь к нему за разъяснениями о вашем будущем. Если же и сообщество к вам глухо, то можно обратится в Google. Но как будет вести себя Google, если сообщество несчастливо, пусть даже и не по вине студента, знает только Google. Сам Google говорит, что готов предоставить своего инженера для разбора этой ситуации. Т.е. по вашему пропозлу, timeline и коду он определяет, кто прав — сообщество или вы. И это решение окончательное.
Хотя думаю, такая ситуация, когда у вас есть работающий код и вы следовали всем правилам, а вами недовольны все — скорее фантастична, нежели реальна.

Если следовать рекомендациям по работе со студентами Google, то со студентом следует попрощаться если:
1. К мидтерму нет обещанного кода
2. Студент не очень коммуникабельный и с ним сложно работать дальше
3. Нет полной уверенности, что студент завершит проект
4. Студент не оправдывает ожиданий сообщества

6. Провальные проекты.

Успешный проект — это три сбалансированных параметра: сроки, бюджет, ресурсы. С бюджетом и ресурсами тут все понятно, остаются сроки, в которые как раз студенты и не укладываются. Чаще всего провальными проектами бывают:

а) Исследовательские, когда вы не можете оценить сложность разработки с самого начала.
Как все начинается?
Самая большая проблема исследовательских проектов это то, что исследования можно проводить до бесконечности, и где та точка, в которой нужно остановится, вы можете так и не узнать. Сначала студент неспешно и воодушевленно читаете разные статьи, книги, копается в исходниках, но потом наступает время кода, а он так и продолжает исследовать. Точка невозврата — это одна неделя до старта кодирования — в это время хорошо бы уже начинать писать «hello world» программы, а не читать. Студенты пишут в рассылку стены текста со ссылками и сомнениями, но менторы уже непрозрачно намекают, что пора бы выбрать хоть что-нибудь и начать кодить. А студент все читает и читает.
Что делать?
Не участвовать в исследовательских проектах. Но если уж угораздило или вас специально позвали, поставьте себе жесткий deadline окончания чтения и начала кодирования по расписанию. Даже если придется потом внести множество изменений, то чисто психологически делать это уже на базе своего кода будет легче, чем делать поздний старт, да и менторам спокойнее будет.

б) Проекты где требуется проектирование сложной архитектуры или API на ранних этапах.
Как все начинается?
Студенты делают одну версию, потом на каком то этапе разработки понимают, что от нее нужно отказаться. Код полностью переписывается, и так два или три раза. Ничего необычного тут нет — нормальный процесс разработки, не все сразу могут найти идеальное решение, которое будет расширяемо. Опыта мало.
Что делать?
Начать разработку как можно раньше, чтобы было время на откаты. Ну и стараться тщательно продумывать все свои архитектурные решения, прежде чем их реализовывать. Обязательно советоваться с менторами в сложных ситуациях, особенно когда началось время кодирования, а рабочего варианта еще нет.

в) Проекты, в которых цель разработки самим сообществом поставлена не четко. Например, если идея вашего проекта изначально описана в стиле «вот есть такая неведомая фигня и мы хотим такую же, но что это такое мы и сами не знаем», то не исключено что на каком-либо этапе разработке вы узнаете, что делаете немного не то, что от вас ожидают.
Как все начинается?
После разгона проекта, когда код уже начал проходить первые тесты, студент вдруг узнает, что результаты должны быть немного не такими. Дальше начинается детальный разбор проекта и пропозла.
Что делать?
Писать подробные отчеты каждую неделю, желательно еще в мае, когда вы только разбираетесь с задачей. Или вы отловите все недоразумения на ранних этапах разработки, или придется пересматривать полезность вашей разработки для сообщества прямо перед мидтермом.

г) Нереалистичные проекты, т.е. проекты, которые требуют времени на реализацию больше, чем три месяца или требования к разработчику через чур высокие (они так и пишут «нам нужен гуру», но студенты думают, что это про них).
Как все начинается?
Студент начинает кодирование по расписанию и тут обнаруживает, что пропускает свои deadline один за другим. Вроде бы код и пишется, но отставание все нарастает и нарастает т.к. обнаруживаются все новые и новые подводные камни, которые были не видны на этапе составления пропозла.
Что делать?
Не брать такие проекты. Если угораздило и организация вменяемая, то попытайтесь договорится о реалистичном результате к августу. Иначе вы просто вылетите, т.к. не оправдали ожиданий сообщества. Можно обратиться к другу. Думаю организации будет все равно, один вы работаете или вам кто-то помогает, главное чтобы код был.

7. Меня выгонят?

А вот это зависит от опыта сообщества. То, как вели себя предыдущие студенты, откладывает неизгладимый отпечаток на сознания менторов. Бывают «молодые» сообщества, которые участвуют первый или второй раз. Они еще не нарывались на студентов-лентяев, поэтому могут верить в вас до конца.

Форс-мажоры.

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

Зачем организации провальные проекты?

Да не за чем, но так получилось. Или сообщество недавно участвует и еще не умеет работать со студентами, не знает, на что они способны или менторы судят по себе — «вот я в его годы мог такое...» (не факт что мог, но ожидают чего-то подобного). Еще может получится так, что у сообщества не было провальных проектов и оно идет по нарастающей, т.е. увеличивает сложность, а студенты тащут. А вот именно в этот раз — ну не затащили. Или у какого-нибудь ментора в голове родилась бредовая идея, ее добавили в список ради разнообразия, а потом и студент нашелся. Конечно, организация ответственна за список идей и, вроде бы, она гарантирует, что любую идею можно реализовать за три месяца, но у вас тоже ведь голова на плечах есть и она думать может. Сомневаетесь — не беритесь за проект, может найдется другой студент, который точно затащит.

Вся правда про Google Summer of Code — часть 3