Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Всем привет!
В этом году Embox участвовал в качестве менторской организации в программе GSoC. В статье я бы хотел рассказать об этом, на наш взгляд, очень интересном опыте.
Пару слов скажу о самой программе GSoC. Google Summer of Code — глобальная программа компании Google направленная на вовлечение студентов в мир СПО. Как следствие, повышение у студентов качества кода, технологической грамотности и навыков в процессах разработки. Перечисленные качества повышаются благодаря тому, что студенты вовлекаются в живые промышленные проекты с достаточно развитыми процессами разработки. Это и должно служить главным мотивом для участия студентов в данной программе. Мотивом менторских организаций прежде всего является развитие и расширение сообщества проекта.
Немного о формальных правилах. К программе допускаются только сообщества представляющие проекты с открытым исходным кодом. Проект, в котором есть репозиторий, но только один разработчик, наверное, не пройдет, ведь необходимо уделять время студентам. Организация, которая хочет принять участие в программе должна заполнить небольшую анкету, заявить минимум двоих администраторов и заполнить страницу с предлагаемыми студентам идеями. Анкета включает в себя короткое описание, контактные данные и ссылку на страницу с идеями. Далее происходит отбор организаций. При принятии проекта по итогам отбора, карточку проекта публикуют на странице менторских организаций программы, и начинается отбор студентов.
Отбор студентов очень трудный для менторов этап. Embox впервые выступал в роли менторской огранизации в программе GSoC. И мы были несколько не готовы к такому количеству желающих принять участие в программе. Формально отбор студентов происходит на основании эссе (proposals), в которых претенденты рассказывают о тех задачах, которые хотели бы выполнить участвуя в проекте и каким образом они предполагают это сделать. Конечно, в эссе есть данные, которые обычно используют в резюме, ну или их можно запросить, но вряд ли этой информации достаточно для понимания сможет или нет студент добиться желаемых результатов. Это и представляет основную сложность для наставников на этом этапе программы.
В разных проектах знакомство и отбор происходит по разному. При обсуждении вопросов связанных с отбором в рассылке для менторов GSoC кто-то рекомендовал провести собеседование по скайпу, кто-то выполнить тестовые задания, кто-то посмотреть подробное резюме. В Embox мы решили поступить следующим образом. Для участия в программе нужно было, во-первых, представиться, написав короткое письмо одному из менторов проекта. Во-вторых, выполнить хотя бы одну задачу из списка на github. И в- третьих, написать официальное эссе на сайте программы.
Первый пункт не вызвал каких-то особых трудностей. Да, были и такие студенты кто подал эссе даже не представившись, но мы их просто не рассматривали. Второй пункт я немного поясню. Embox, как все достаточно развитые проекты, имеет свои собственные процессы разработки, и обычно студентам банально может не хватать практики участия в промышленных и распределенных проектах. Кроме того, Embox — операционная система. Это обычно новая область с точки зрения практики для студентов. И прежде чем начать хоть что-то улучшать проекте, нужно научиться собирать, запускать, отлаживать и вносить изменения в код, понять процессы принятые в проекте, тот же git workflow и так далее.
Нам не хотелось заниматься подобными вещами в активной фазе программы, и мы постарались сделать это на предварительном этапе. Мы создали очень простые задачи Good First Issue направленные на понимание процессов проекта, минимальные знания языка Си, умение читать документацию и искать информацию в интернете. По сути, мы были уверены в том, что после выполнения подобных задач студент сможет провести какие-то изменения в коде и подготовить Pull Request.
На этом предварительные требования для официальной подачи заявки считались выполненными. Но студенты могли продолжать участвовать в проекте выполняя другие задачи из списка на github и предлагать свои улучшения и изменения. Единственная просьба, которая у нас была, не брать вторую Good First Issue. Мы хотели, чтобы у всех были равные возможности, а создание большого количества простых задач оказалось непростой задачей. Во всем остальном мы старались помочь всем желающим студентам, начиная от правил оформления PR и работы с git-ом, и до разъяснения архитектуры и особенностей проекта.
Те студенты, кто продолжил по мере возможности участвовать в проекте, написали очень хорошие эссе. Это не удивительно, ведь таким образом им удалось глубже погрузиться в проект, прочувствовать задачу, которую они хотели бы выполнить, да и просто набраться опыта.
Многие эссе этих студентов отличались не только проработанностью плана работ, но и темами. У нас на странице с идеями был опубликован некоторый список предполагаемых тем, но мы изначально рассматривали его только как демонстрацию возможных направлений. И были очень рады когда нам стали предлагать собственные темы.
Нам важно, чтобы студент мог заниматься интересной именно ему темой. Мы видим в этом дополнительную мотивацию для студентов. Но, конечно, собственная тема это не обязательное условие. У нас были очень интересные темы, и многие студенты, даже погрузившись в проект, хотели заниматься темой из предложенного списка.
По результатам этого периода в проект подали более 30 эссе. Было не менее пяти очень хороших студентов, которые выполняли не только минимальные требования, но и общались с нами по другим задачам, старались их выполнить, предлагали собственные идеи, в общем, проявляли интерес к проекту. Но к сожалению по итогам распределения нам досталось только два слота для студентов, пришлось чуть ли не кидать монетку. К счастью, как мы выяснили чуть позже, некоторые из хороших студентов прошли в другие проекты.
Мы выбрали двух студентов Erick Cafferata и Yuta Sakamoto. Оба предложили собственные идеи. Erick реализовать USB device режим для STM32. Yuta перенести Embox на плату MAiX-Bit с архитектурой RISC-V. Что интересно, у обоих в приветственном письме были задачи из нашего списка. Но, как и предполагалось, после более глубокого погружения в проект они лучше сформулировали свои идеи.
Следующим в официальном плане программы шел этап знакомства, когда студенты более плотно общаются с комьюнити и продолжают изучать проект. Поскольку оба студента уже были вовлечены в проект, то для них это было скорее продолжением знакомства. Конечно было и отличие. Так как мы уже знали какие темы студентам предстоит реализовать, мы предлагали им задачи близкие к выбранным направлениям.
По результатам этого этапа программы были выполнены несколько подготовительных задач, которые, на мой взгляд, позволили более успешно двигаться студентам по их планам в будущем.
Летом начался основной этап программы — этап разработки, в результате которого должен появиться новый код. Данный этап разделен на три части, каждая по месяцу. После каждой части проводится аттестация. Предполагается, что студенты должны работать равномерно. И по результатам каждого месяца мы должны подтверждать, что студенты придерживаются плана.
На практике мы заметили различную активность студентов. Порой даже казалось, что активность была ниже чем на предварительном этапе. Выяснилось, что у них началась сессия или они были загружены учебой и не могли уделять достаточно времени участию в программе. Зато они очень продуктивно трудились в другие периоды. Оказалось, что подобное происходило не только в нашем проекте. По результатам саммита менторов даже было предложено упростить правила и позволить студентам и менторским организациям согласовывать график работы студентов.
Общение является важной частью коллективной разработки. Конечно, у Embox, как и у других проектов с открытым кодом, есть свои механизмы коммуникации между разработчиками. У Embox есть телеграм чаты ( английский, русский, новости) и списки рассылки (английская (embox-devel[at]googlegroups.com) и русская (embox-ru[at]googlegroups.com )).
Но, конечно, некоторые вещи, которые обсуждаются со студентами, не хочется делать публичными. К тому же, студенты порой стесняются задавать вопросы в общий чат. Кроме того, GSoC международная программа, и для некоторых существует языковой барьер. У нас один из студентов написал что ему трудно общаться на английском. В результате для общения с каждым из студентов мы создали приватные чаты, в которых были два ментора: один основной и один помогающий. Основное общение по конкретным проектам происходило в этих чатах. Конечно, общее для проекта общение происходило в общих для проекта местах (телеграмм чат или github).
Но, конечно, основная часть программы направлена на разработку. На первых этапах студенты должны были следовать правилам сторонних разработчиков. Клонируется репозиторий, разрабатывается модуль, предлагается PR, этот PR ревьюится, одобряется и затем мерджиться в проект. То есть сторонние разработчики используют собственный репозиторий. Для того чтобы проверить изменения необходимо переключиться в этот репозиторий. Это вполне нормально, когда речь идет только о проверке, но когда речь идет о каком-нибудь совете или одну задачу разрабатывают несколько человек, это может добавить сложности. Чтобы этого избежать обоих студентов добавили в команду Embox и тем самым позволили им создавать бранчи в основном репозитории. В результате это оказалось верное решение, ведь на финальной стадии программы мы достаточно плотно работали со студентами, и получилось что студенты приобрели опыт в командной разработке.
Оба студента успешно завершили программу. Erick продемонстрировал корректное отображение STM32 подключенного к компьютеру с помощью утилиты lsusb. А Yuta с помощью командной утилиты Embox продемонстрировал управление светодиодом. Конечно, Erick еще хотел добавить функционал какого-нибудь устройства, и даже разработал ECM-ACM (виртуальный компорт). А Yuta в планах хотел добавить поддержку модуля шифрования. Но это была недооценка сложности предполагаемых работ. Я считаю, что результаты полученные за три месяца в такой сложной области, как системное программирование, впечатляют. Ну и главное, студенты получили великолепный опыт командной работы, лучше познакомились с миром opensource и значительно улучшили свои технические навыки.
В этом году Embox участвовал в качестве менторской организации в программе GSoC. В статье я бы хотел рассказать об этом, на наш взгляд, очень интересном опыте.
Пару слов скажу о самой программе GSoC. Google Summer of Code — глобальная программа компании Google направленная на вовлечение студентов в мир СПО. Как следствие, повышение у студентов качества кода, технологической грамотности и навыков в процессах разработки. Перечисленные качества повышаются благодаря тому, что студенты вовлекаются в живые промышленные проекты с достаточно развитыми процессами разработки. Это и должно служить главным мотивом для участия студентов в данной программе. Мотивом менторских организаций прежде всего является развитие и расширение сообщества проекта.
Немного о формальных правилах. К программе допускаются только сообщества представляющие проекты с открытым исходным кодом. Проект, в котором есть репозиторий, но только один разработчик, наверное, не пройдет, ведь необходимо уделять время студентам. Организация, которая хочет принять участие в программе должна заполнить небольшую анкету, заявить минимум двоих администраторов и заполнить страницу с предлагаемыми студентам идеями. Анкета включает в себя короткое описание, контактные данные и ссылку на страницу с идеями. Далее происходит отбор организаций. При принятии проекта по итогам отбора, карточку проекта публикуют на странице менторских организаций программы, и начинается отбор студентов.
Отбор студентов очень трудный для менторов этап. Embox впервые выступал в роли менторской огранизации в программе GSoC. И мы были несколько не готовы к такому количеству желающих принять участие в программе. Формально отбор студентов происходит на основании эссе (proposals), в которых претенденты рассказывают о тех задачах, которые хотели бы выполнить участвуя в проекте и каким образом они предполагают это сделать. Конечно, в эссе есть данные, которые обычно используют в резюме, ну или их можно запросить, но вряд ли этой информации достаточно для понимания сможет или нет студент добиться желаемых результатов. Это и представляет основную сложность для наставников на этом этапе программы.
В разных проектах знакомство и отбор происходит по разному. При обсуждении вопросов связанных с отбором в рассылке для менторов GSoC кто-то рекомендовал провести собеседование по скайпу, кто-то выполнить тестовые задания, кто-то посмотреть подробное резюме. В Embox мы решили поступить следующим образом. Для участия в программе нужно было, во-первых, представиться, написав короткое письмо одному из менторов проекта. Во-вторых, выполнить хотя бы одну задачу из списка на github. И в- третьих, написать официальное эссе на сайте программы.
Первый пункт не вызвал каких-то особых трудностей. Да, были и такие студенты кто подал эссе даже не представившись, но мы их просто не рассматривали. Второй пункт я немного поясню. Embox, как все достаточно развитые проекты, имеет свои собственные процессы разработки, и обычно студентам банально может не хватать практики участия в промышленных и распределенных проектах. Кроме того, Embox — операционная система. Это обычно новая область с точки зрения практики для студентов. И прежде чем начать хоть что-то улучшать проекте, нужно научиться собирать, запускать, отлаживать и вносить изменения в код, понять процессы принятые в проекте, тот же git workflow и так далее.
Нам не хотелось заниматься подобными вещами в активной фазе программы, и мы постарались сделать это на предварительном этапе. Мы создали очень простые задачи Good First Issue направленные на понимание процессов проекта, минимальные знания языка Си, умение читать документацию и искать информацию в интернете. По сути, мы были уверены в том, что после выполнения подобных задач студент сможет провести какие-то изменения в коде и подготовить Pull Request.
На этом предварительные требования для официальной подачи заявки считались выполненными. Но студенты могли продолжать участвовать в проекте выполняя другие задачи из списка на github и предлагать свои улучшения и изменения. Единственная просьба, которая у нас была, не брать вторую Good First Issue. Мы хотели, чтобы у всех были равные возможности, а создание большого количества простых задач оказалось непростой задачей. Во всем остальном мы старались помочь всем желающим студентам, начиная от правил оформления PR и работы с git-ом, и до разъяснения архитектуры и особенностей проекта.
Те студенты, кто продолжил по мере возможности участвовать в проекте, написали очень хорошие эссе. Это не удивительно, ведь таким образом им удалось глубже погрузиться в проект, прочувствовать задачу, которую они хотели бы выполнить, да и просто набраться опыта.
Многие эссе этих студентов отличались не только проработанностью плана работ, но и темами. У нас на странице с идеями был опубликован некоторый список предполагаемых тем, но мы изначально рассматривали его только как демонстрацию возможных направлений. И были очень рады когда нам стали предлагать собственные темы.
Нам важно, чтобы студент мог заниматься интересной именно ему темой. Мы видим в этом дополнительную мотивацию для студентов. Но, конечно, собственная тема это не обязательное условие. У нас были очень интересные темы, и многие студенты, даже погрузившись в проект, хотели заниматься темой из предложенного списка.
По результатам этого периода в проект подали более 30 эссе. Было не менее пяти очень хороших студентов, которые выполняли не только минимальные требования, но и общались с нами по другим задачам, старались их выполнить, предлагали собственные идеи, в общем, проявляли интерес к проекту. Но к сожалению по итогам распределения нам досталось только два слота для студентов, пришлось чуть ли не кидать монетку. К счастью, как мы выяснили чуть позже, некоторые из хороших студентов прошли в другие проекты.
Мы выбрали двух студентов Erick Cafferata и Yuta Sakamoto. Оба предложили собственные идеи. Erick реализовать USB device режим для STM32. Yuta перенести Embox на плату MAiX-Bit с архитектурой RISC-V. Что интересно, у обоих в приветственном письме были задачи из нашего списка. Но, как и предполагалось, после более глубокого погружения в проект они лучше сформулировали свои идеи.
Следующим в официальном плане программы шел этап знакомства, когда студенты более плотно общаются с комьюнити и продолжают изучать проект. Поскольку оба студента уже были вовлечены в проект, то для них это было скорее продолжением знакомства. Конечно было и отличие. Так как мы уже знали какие темы студентам предстоит реализовать, мы предлагали им задачи близкие к выбранным направлениям.
По результатам этого этапа программы были выполнены несколько подготовительных задач, которые, на мой взгляд, позволили более успешно двигаться студентам по их планам в будущем.
Летом начался основной этап программы — этап разработки, в результате которого должен появиться новый код. Данный этап разделен на три части, каждая по месяцу. После каждой части проводится аттестация. Предполагается, что студенты должны работать равномерно. И по результатам каждого месяца мы должны подтверждать, что студенты придерживаются плана.
На практике мы заметили различную активность студентов. Порой даже казалось, что активность была ниже чем на предварительном этапе. Выяснилось, что у них началась сессия или они были загружены учебой и не могли уделять достаточно времени участию в программе. Зато они очень продуктивно трудились в другие периоды. Оказалось, что подобное происходило не только в нашем проекте. По результатам саммита менторов даже было предложено упростить правила и позволить студентам и менторским организациям согласовывать график работы студентов.
Общение является важной частью коллективной разработки. Конечно, у Embox, как и у других проектов с открытым кодом, есть свои механизмы коммуникации между разработчиками. У Embox есть телеграм чаты ( английский, русский, новости) и списки рассылки (английская (embox-devel[at]googlegroups.com) и русская (embox-ru[at]googlegroups.com )).
Но, конечно, некоторые вещи, которые обсуждаются со студентами, не хочется делать публичными. К тому же, студенты порой стесняются задавать вопросы в общий чат. Кроме того, GSoC международная программа, и для некоторых существует языковой барьер. У нас один из студентов написал что ему трудно общаться на английском. В результате для общения с каждым из студентов мы создали приватные чаты, в которых были два ментора: один основной и один помогающий. Основное общение по конкретным проектам происходило в этих чатах. Конечно, общее для проекта общение происходило в общих для проекта местах (телеграмм чат или github).
Но, конечно, основная часть программы направлена на разработку. На первых этапах студенты должны были следовать правилам сторонних разработчиков. Клонируется репозиторий, разрабатывается модуль, предлагается PR, этот PR ревьюится, одобряется и затем мерджиться в проект. То есть сторонние разработчики используют собственный репозиторий. Для того чтобы проверить изменения необходимо переключиться в этот репозиторий. Это вполне нормально, когда речь идет только о проверке, но когда речь идет о каком-нибудь совете или одну задачу разрабатывают несколько человек, это может добавить сложности. Чтобы этого избежать обоих студентов добавили в команду Embox и тем самым позволили им создавать бранчи в основном репозитории. В результате это оказалось верное решение, ведь на финальной стадии программы мы достаточно плотно работали со студентами, и получилось что студенты приобрели опыт в командной разработке.
Оба студента успешно завершили программу. Erick продемонстрировал корректное отображение STM32 подключенного к компьютеру с помощью утилиты lsusb. А Yuta с помощью командной утилиты Embox продемонстрировал управление светодиодом. Конечно, Erick еще хотел добавить функционал какого-нибудь устройства, и даже разработал ECM-ACM (виртуальный компорт). А Yuta в планах хотел добавить поддержку модуля шифрования. Но это была недооценка сложности предполагаемых работ. Я считаю, что результаты полученные за три месяца в такой сложной области, как системное программирование, впечатляют. Ну и главное, студенты получили великолепный опыт командной работы, лучше познакомились с миром opensource и значительно улучшили свои технические навыки.