Думаю тема не новая и все знают что за лето студент может заработать $5000. В Интернете полно рассказов о том «как я круто затащил летом», но мало кто говорит об изнанке данного мероприятия.
На первый взгляд все просто — подай пропозал и получи стипендию. Но если бы все было так просто, российских студентов не было так мало. А их действительно мало. Как-то порывшись в статистике, я обнаружила, что с моего города я вообще единственный студент, когда-либо участвствовавший в GSoC (на тот год, сейчас нас уже больше). А это очень плохо, т.к. знаю очень много людей, которые умнее меня и они почему-то не участвовали или не прошли отбор.
1. Как все начинается?
Где-то в середине зимы Google радует мир своим решением провести лето кодинга. Т.к. мероприятие проводится уже не первый год, то организации уже наготове. В феврале в рассылках начинаются первые шевеления на тему «ну надо бы придумать, что мы хотим, чтобы нам сделали». В начале марта организации уже должны подать заявки, т.е. в рассылках уже есть черновой лист идей. В середине марта Google публикует лист организаций. С этого момента нужно активно шевелиться.
На сайтах сообществ уже появляются листы с идеями и вы должны их начать изучать как можно быстрее. Времени очень мало. Приблизительно, у вас есть неделя на выбор организаций и проектов, на которые вы будете подавать заявку. Потом вы должны начать работать над пропозалом.
Пропозал (proposal) — заявка на участие. Включает вашу анкету и детальное описание проекта, который вы собираетесь кодить. Вы можете подать несколько таких заявок, но работать будете только по одной.
Зарегистрировались, дальше подписывайтесь на лист рассылки для студентов-кандидатов.
2. Кто может?
Все студенты и аспиранты на любом году обучения, даже на последнем.
3. Как выбрать организацию?
В списке организаций будут указаны ключевые навыки программиста. Обычно в этой графе языки программирования. Учтите, что если организация пишет С++, то вы должны хорошо знать С++ и у вас должен быть хоть какой-нибудь опыт разработки на этом языке. Есть такая особая категория студентов, которая воспринимает эти требования как то, что они изучат в ходе выполнения проекта. Вас никто ничему учить не будет, это работа, а не стажировка с нянькой.
Часто студенты бегут в популярные организации, такие как gnome, kde, apache, gimp, google и т.д. Понятно, что проекты там интересные, но таких заинтересованных будет очень много. К тому же большой вопрос — что мешало вам сделать что-нибудь для этого сообщества не в рамках лета кодинга?
Чтобы отсеять народ, организации очень часто вводят дополнительные правила. Например, правило одного или двух патчей, или один год контрибьютинга (т.е. вы уже год участвуете в разработке). Так что перед тем, как вцепиться в понравившийся проект, внимательно прочитайте дополнительные правила, возможно ваша заявка даже не будет рассмотрена.
Что еще нужно знать?
Так же у вашей организации может быть куча других правил. Например, требования к стилю кодирования или формам отчета. Обычно такая дополнительная информация указана на сайте. Внимательно изучите ее, а то вдруг какой-то из пунктов противоречит вашей религии.
Хорошо бы еще посмотреть статистику участия организации за прошлые года — какие были проекты, успешно ли они завершились, был ли код внесен в релиз.
Выбрали, подпишитесь к рассылке. Подписались — пошарьте в архиве и почитайте предыдущие письма. Возможно, там будет информация по вашему проекту.
4. Выбираем проект.
Самое сложное — выбрать проект. Даже если тема вам очень нравится и вы просто трепещите от одной мысли о кодировании этого проекта — вы должны оценить все за и против очень трезво. Почему-то никто из студентов не думает, что летом может не пройти экватор (Mid-term evaluations deadline) и вылететь из проекта.
Все проекты делятся на два типа — исследовательские и рутинные. Вы должны понимать, что если организация сама не занимается разработкой чего-либо, то на то есть причины.
1. Слишком сложно — нужно много читать и изучать данный вопрос.
2. Слишком скучно — переписывание какого-нибудь модуля, кодирование по доке или другая рутинная и неинтересная работа.
3. Слишком непонятно — организация знает, что должно быть на выходе, но как именно реализовать — не знает т.к. ни у кого из команды нет соответствующих знаний.
Если почитать русскую рассылку и список принятых проектов, то складывается ощущение, что наши студенты страдают гигантоманией. Почти все русскоязычные программисты выбирают исследовательские проекты, напрямую связанные с их диссертациями или дипломами. Просто переписать какой-нибудь кусок кода обычно не комильфо. Мое мнение, что с этих проектов проще всего вылететь, т.к. на начальном этапе разработки еще нет точного представления о сложности реализации. Одно дело, когда вы уже делали нечто подобное, другое когда только собираетесь. Если у вас есть выбор между скучной реализацией чего-то простого и исследованием — выбирайте рутину. Опыта у вас нет и время планировать вы еще не умеете, а с исследованием можно закопаться на срок дольше, чем длится лето.
Никогда и ни за что.
Как-то в один год была организация, которая предлагала студентам реализовать очень сложные исследовательские проекты. Уровень исследования — это кандидатская, причем не отечественная. По моим оценкам на приличное исследование (даже не реализацию) нужно пол года. А реализация такого проекта может занять год. На кого были рассчитаны такие задания, для меня загадка. Возможно, это была «заготовка» для своих студентов, которые уже вели исследования и начинали разработку. Возможно, кто-то надеялся дешево получить чьи-нибудь наработки. В общем — нереалистичных проектов вам стоит избегать в любом случае.
5. Пишем пропозал.
После выбора проекта вы должны написать пропозал. Официально вы должны запостить свое предложения в начале апреля. Не официально — к этой дате организация уже имеет черновой список принятых студентов.
Пропозалы пишутся в период общения с менторами, т.е. вы пишете, общаетесь и дописываете. В этот период менторы с вами знакомятся и решают, можно ли с вами работать или нет. Но можно и не общаться — с первого раза запостить идеальный пропозал и ответить на парочку небольших вопросов в комментариях (это шутка, если что).
Пропозал — ваш план реализации, можно сказать ТЗ (кто доучился до старших курсов — знает, что это такое). Когда GSoC только раскручивался, то организаторы требовали от студентов писать доказательство необходимости реализации проекта. Это выглядело очень забавно — организаторы выставляли идеи, а вы потом им доказывали, что они точно хотят их реализацию. Сейчас вроде такого нет (только если вы сами ни предложите идею, а так тоже можно) и студенты пишут по пунктам то, как они все таки будут кодить. Еще организация может включить в пропозал свои вопросы, например попросить написать кратко о себе, ваш опыт разработки, ссылки на ваши проекты и т.д.
Общее описание.
Сначала вы пишите о том, что вы должны сделать, т.е. вход и выход. Причем вы точно должны понимать, что именно вы реализуете и какой результат гарантируете к концу августа. Описываете проблему и пути ее решения. Можно добавить ссылки на статьи или другие ресурсы, какими вы будете пользоваться при работе.
Техническое описание.
Общее техническое описание. Т.е. «я реализую такую-то функцию в таком-то модуле». В этой части вы должны показать, что хорошо разобрались с исходниками, смогли у себя все скомпилить и запустить. Хорошо бы создать бранч и сделать пару коммитов.
Timeline
Вы должны разделить свой проект на подзадачи и расписать, когда и что вы будете кодить. Очень важный пункт пропозала. Если вам кажется, что вы закодите весь проект за 2 недели, значит вы успеете его реализовать за 3 месяца. Если вам кажется, что вы успеваете в притык — вы не успеете совсем. Ваш оптимизм — ваш худший враг. Если читая данный текст, вы думаете, что вы-то уж точно затащите, а по ночам вам кодится отлично, и не спать вы можете по 48 часов — пойдите попейте водички и сделайте несколько глубоких вдохов, может отпустит. Лучше заложить в план меньший объем работы, а потом обрадовать вашего ментора дополнительным кодом, чем пропустить deadline. Пишите ваш план пессимистично — если у вас будет затык, вы не вылетите, а если все пойдет хорошо — никто вас не обвинит в дополнительной работе.
Самый важный момент — это ваш первый deadline. Т.е. первая дата к которой вы обещаете предоставить кусок рабочего кода. Обычно начало июня. Если у вас рутинный проект — добавьте себе неделю, если исследовательский — добавьте две. Нет ничего хуже, чем пропустить первый deadline. Пусть лучше у вас будет дополнительное время и вы сделаете больше, чем обещали, чем вы начнете отставать с первых же дней. К тому же на начальной стадии разработки проект всегда медленнее двигается, чем ближе к концу, когда вы уже в теме.
Самое продуктивное время разработки — это две недели до мидтерма и три недели после. Тогда вы уже привыкнете к коду и хорошо разберетесь с задачей. Постарайтесь спланировать свое время так, чтобы основной объем работы выпал на это время.
Спланируйте себе отпуск. Отдых вам необходим, и тут нет ничего противозаконного — вы имеете право на каникулы. Планируйте каникулы на время мидтерма или после — так вы отдохнете и из проекта не выпадете.
Не дробите проект на слишком мелкие подзадачи — так вы не оставите себе места для маневра. Бывает так, что некоторые подзадачи приходится переносить на более поздний срок, некоторые на более ранний.
Оставьте себе неделю после каждой крупной задачи на тестирование. Тестирование — это ваша подушка безопасности на тот случай, если вы что-то не успеете. К тому же очень часто невозможно заранее спланировать весь объем работ, а так у вас будет дополнительное время для форс мажора.
Не оставляйте на август ничего важного. В середине августа pencils down. Значит неделя до этой даты — финальное тестирование. Если вас еще попросят написать документацию или внести какие-нибудь финальные изменения, то на это уйдет еще одна неделя.
6. Колличество и качетсво.
Когда-то давно Google рекомендовал студентам постить несколько пропозалов. В то время эта рекомендация была актуальна, т.к. основная масса студентов кидалась на известные сообщества, а на неизвестные подавалось очень мало заявок. Но сейчас ситуация изменилась — студентов желающих поучаствовать стало больше, да и люди реально оценили свои шансы покодить в gcc или в gnome.
Думаю, правильнее выбрать 2 или 3 сообщества и начать работать с пропозалами. Если в каком-то сообществе работа идет лучше, чем в других, то нужно кидать все силы на этот пропозал. Останется время — можно сделать второй. Больше, думаю, будет сложно, т.к. без работы с исходниками хороший пропозал не составишь.
7. Оценочный период.
После того, как вы запостили ваш пропозал, менторы начинают его оценивать, даже если оценочный период еще не начался. После постинга вам следует начать дисскусию о своем проекте в рассылке — сделайте ваш пропозал общедоступным и киньте на него ссылку в рассылку. В некоторых организациях менторы беседуют со студентами через рассылку или IRC, а не в камментах к пропозалу. У них там демократия, т.е. каждый должен выставить свою оценку, а не только ментор вашего проекта. Если проектов много, то и времени для обсуждения нужно много. Вот почему запостенные в самый последний день пропозалы практически не имеют шансов на успех.
Когда начинается оценочный период менторы уже знают, кого возьмут. Возможно, вам еще будут задавать вопросы по технической реализации, но только для того чтобы убедится в том, что вы заслуживаете положительного отзыва. Так что, если увидите в каментах вопрос не от вашего ментора — не удивляйтесь и не филоньте. Если интересуются, значит будут по вам голосовать.
Коллизии.
Если один и тот же студент проходит по двум проектам, то его судьба решается на второй неделе оценочного периода. Вроде бы вы должны выставить приоритет проектов, но как точно этот механизм сейчас работает, я не знаю. Раньше решалось все через чат. Т.е. менторы связывались с основным и запасным студентом и все решалось online.
Еще были случаи, когда студент, проходивший в две организации, в итоге так и не попал ни в одну. Так что если у вас 2 хороших пропозла, лучше сразу сказать разработчикам, что в случае коллизий вы хотите к ним.
Google bugs.
Не знаю почему, но почти каждый год Google радует студентов рассылкой предварительных результатов. В рассылку попадают не все, и почему это происходит никто не знает. Как-то (вроде даже и не раз, в 2011 точно такое было) студентам были разосланы не только предварительные результаты, но и оценки менторов — «фигня», «полная фигня», «лучше не смотреть». Мне повезло попасть в рассылку только один раз. За 4 дня до оглашения результатов на почту пришло письмо без текста с темой congratulations. В 9 из 10 этим результатам можно верить, но не в случаях коллизий. Так один ментор очень негодовал по поводу поздравления студента, когда тот еще был в коллизии.
8. Как нас выбирают?
По интернету бродит много советов: что сделать, чтобы тебя выбрали. По моему опыту и опыту моих друзей могу сказать, что таких правил не существует. Каждая организация действует исходя из собственного опыта, их убеждений, предпочтений, текущей ситуации с пропозалами и т.д.
Первый совет, который вам дают — это общаться с ментором на прямую. Мое мнение — это не совсем хорошо и не демократично. Кстати идея демократии проходит жирной красной линией через весь GSoC. Не все менторы любят приватное обсуждение. Во-первых, у них демократия и решение о вашем приеме должны одобрить остальные. Во-вторых, другие студенты тоже могут интересоваться этим проектом и ментору проще отвечать в рассылке, нежели приватно. По этой же причине не очень хорошо обсуждать проект в IRC. В-третьих, не во всех организациях ментор назначается сразу. Бывает, вы узнаете точно с кем работаете только после оглашения результатов.
Общение в IRC. Да они любят IRC, потому что это лучший способ узнать вас по лучше. Но тут есть несколько минусов — разница во времени, языковый барьер и текущая занятость. Все таки рассылка лучше, т.к. любой участник сообщества может присоединиться к разговору в любое время. Но если организация хочет и ментор настаивает — чатиться придется много. Можно сказать это хороший знак — на вас готовы потратить очень много времени, значит, скорее всего возьмут.
Грязные хаки.
Нет, конечно можно предпринять некоторые действия, которые сильно увеличат ваши шансы на успех, но тут только один путь — идти по нарастающей.
Больше патчей. Вас просят сделать пару патчей, так сделайте 3 или 4. Так вы выделитесь среди других кандидатов.
Ранняя заявка. Как правило заявки (хорошие заявки) поданные раньше имеют больше шансов на успех. Но тут есть еще один аспект — другие студенты. Если какой-нибудь студент будет просматривать список идей и обнаружит, что на этот проект уже подано несколько заявок, то он может отказаться от него, даже если хорошо подходит для этой разработки. Ваша задача подать свою заявку как можно раньше, сделать ее паблик и скинуть в рассылку. Так вы «пометите» территорию и начнете дискуссию с менторами. Потом вы можете переписать пропозал, добавить больше деталей — в общем сделать все, чтобы показать сообществу, что с вами можно работать, а другим студентам, что «место занято».
Код проекта. Добавьте к своему пропозалу кусок рабочего кода вашего проекта. И сделайте это быстро, так, чтобы остальные студенты не стали подавать заявку на ваш проект и вас бы ни с кем не сравнивали. Да даже если подадут. Они будут обещать, что весь май будут читать доки и разбираться с исходниками, а вы уже все прочли и частично закодили. Так вы и правило патча обойдете и предоставите образец кода.
Увеличить сложность. Если вы в состоянии в качестве патча написать кусок кода проекта, то вы можете пообещать сделать больше, чем от вас хотят. Небольшое расширение идеи будет очень выгодно смотреться на фоне остальных заявок. Иногда сообщество заранее указывает в описании идеи несколько уровней сложности, т.е. можно сделать фичу «a», но еще и фичу «b», а если сделаете еще и «c», то совсем будет круто. Так они пытаются получить студента который сделает как можно больше за деньги Google.
Некондиционный проект. Иногда в крупных организациях (ну и в мелких тоже, но реже) встречаются проекты, которые затрагивают какой-нибудь раздел Computer Science. Если это не искусственный интеллект в игре и не поиск, то желающих покодить будет немного или вообще никто не позарится. Короче, лакомый кусок для русского студента. Большой организации будет не жалко дать вам слот — разнообразия ради, ну а вы сделаете свой научный проект.
Портфолио. Кандидаты, которые могут предоставить ссылки на код своего собственного проекта в репозитории, смотрятся выгоднее, чем остальные. Иногда такое требование обязательное, т.к. менторам хочется посмотреть на пример вашего кода. Так что, если у вас есть свой маленький проект, то самое время причесать его и выложить в репозиторий.
9. Волонтерство.
Иногда организация предлагает волонтерство, т.е. все то же самое, только без стипендии. Если ваш проект не приняли (слотов не хватило или вы очень поздно запостили свой пропозал, или какая другая причина) и у вас есть возможность стать волонтером — соглашайтесь. Завершите проект успешно — в следующем году значит точно пройдете; на вас не обращают внимание — тоже хорошо, вы не попали в организацию, которая не умеет работать со студентами, в следующем году выберите другую. Старайтесь получить выгоду из любой ситуации — опыт работы в жестких временных рамках может оказаться куда ценнее денег.
Автор: awRabbit
