Olá a todos!
Este ano a Embox participou como organização mentora do programa GSoC . Neste artigo gostaria de falar sobre isso, em nossa opinião, uma experiência muito interessante.
Direi algumas palavras sobre o próprio programa GSoC. Google Summer of Code é o programa global do Google voltado para envolver os alunos no mundo do código aberto. Como resultado, os alunos melhoraram a qualidade do código, o conhecimento tecnológico e as habilidades nos processos de desenvolvimento. Essas qualidades são reforçadas pelo fato de que os alunos estão envolvidos em projetos industriais vivos com processos de desenvolvimento suficientemente desenvolvidos. Este deve ser o principal motivo da participação dos alunos neste programa. A motivação das organizações mentoras é principalmente o desenvolvimento e a expansão da comunidade do projeto.
Um pouco sobre as regras formais. Apenas comunidades que representam projetos de código aberto têm permissão para o programa. Um projeto que tem um repositório, mas apenas um desenvolvedor provavelmente irá falhar, porque você precisa dedicar tempo aos alunos. Uma organização que deseja participar do programa deve preencher um pequeno questionário, declarar pelo menos dois administradores e preencher uma página com as ideias propostas aos alunos. O questionário inclui uma breve descrição, detalhes de contato e um link para a página de uma ideia. Em seguida, vem a seleção das organizações. Quando o projeto é aceite com base nos resultados da seleção, a ficha do projeto é publicada na página das entidades mentoras do programa, e dá-se início à seleção dos alunos.
A seleção de alunos é uma etapa muito difícil para os mentores. Pela primeira vez, a Embox atuou como uma organização mentora no programa GSoC. E estávamos um pouco despreparados para tantas pessoas dispostas a participar do programa. Formalmente, a seleção dos alunos é baseada em ensaios (propostas), nos quais os candidatos falam sobre as tarefas que gostariam de realizar com a participação no projeto e como pretendem fazê-lo. Claro, a dissertação contém dados que geralmente são usados em um currículo, bem, ou você pode solicitá-los, mas essas informações provavelmente não serão suficientes para entender se o aluno será ou não capaz de alcançar os resultados desejados. Essa é a principal dificuldade dos mentores nesta fase do programa.
Em diferentes projetos, o conhecimento e a seleção ocorrem de maneiras diferentes. Ao discutir questões relacionadas à seleção na lista de discussão para mentores GSoC, alguém recomendou uma entrevista no Skype, alguém para completar tarefas de teste, alguém para ver um currículo detalhado. Na Embox, decidimos fazer o seguinte. Para participar do programa, foi necessário, em primeiro lugar, apresentar-se escrevendo uma breve carta a um dos mentores do projeto. Em segundo lugar, conclua pelo menos uma tarefa da lista no github. E em terceiro lugar, escreva um ensaio oficial no site do programa.
O primeiro ponto não causou nenhuma dificuldade particular. Sim, houve alguns alunos que enviaram redações sem se apresentarem, mas nós simplesmente não os consideramos. Vou explicar um pouco o segundo ponto. A Embox, como todos os projetos razoavelmente desenvolvidos, tem seus próprios processos de desenvolvimento e, geralmente, os alunos podem simplesmente não ter a prática de participar de projetos industriais e distribuídos. Além disso, Embox é um sistema operacional. Normalmente, esta é uma nova área em termos de prática para os alunos. E antes de começar a melhorar o projeto pelo menos alguma coisa, você precisa aprender como construir, executar, depurar e fazer alterações no código, entender os processos adotados no projeto, o mesmo fluxo de trabalho git e assim por diante.
Não queríamos fazer essas coisas na fase ativa do programa e tentamos fazê-lo na fase preliminar. Criamos tarefas muito simples do Good First Issue destinadas a compreender os processos do projeto, um conhecimento mínimo de C, a capacidade de ler documentação e pesquisar informações na Internet. Na verdade, estávamos confiantes de que, após concluir essas tarefas, o aluno será capaz de fazer algumas alterações no código e preparar um Pull Request.
Com isso, foram considerados atendidos os pré-requisitos para o depósito oficial do pedido. Mas os alunos podem continuar a participar do projeto completando outras tarefas da lista no github e sugerindo melhorias e mudanças. O único pedido que tínhamos era não aceitar a segunda edição do Good First. Queríamos que todos tivessem oportunidades iguais e criar um grande número de tarefas simples não era uma tarefa fácil. Em todos os outros aspectos, tentamos ajudar todos os alunos interessados, desde as regras para configurar o PR e trabalhar com o git, até explicar a arquitetura e os recursos do projeto.
Os alunos que continuaram a participar do projeto sempre que possível escreveram redações muito boas. Isso não é surpreendente, pois desta forma eles conseguiram mergulhar mais fundo no projeto, sentir a tarefa que gostariam de realizar e apenas ganhar experiência.
Muitas das redações desses alunos diferiram não só na elaboração do plano de trabalho, mas também nos tópicos. Tínhamos uma lista de tópicos sugeridos postada em nossa página de ideias, mas inicialmente a consideramos apenas como uma demonstração de possíveis direções. E ficamos muito felizes quando eles começaram a nos oferecer seus próprios temas.
É importante para nós que o aluno possa tratar de um assunto que lhe interessa. Vemos isso como uma motivação adicional para os alunos. Mas, é claro, seu próprio tema não é um pré-requisito. Tínhamos temas muito interessantes, e muitos alunos, mesmo imersos no projeto, queriam tratar de um tema da lista proposta.
Como resultado desse período, mais de 30 ensaios foram submetidos ao projeto. Foram pelo menos cinco alunos muito bons que não só cumpriram os requisitos mínimos, mas também comunicaram connosco noutras tarefas, tentaram cumpri-los, deram as suas próprias ideias, em geral, mostraram interesse pelo projecto. Mas infelizmente, como resultado da distribuição, conseguimos apenas dois slots para alunos, quase tivemos que jogar uma moeda. Felizmente, como descobrimos um pouco mais tarde, alguns dos bons alunos seguiram para outros projetos.
Selecionamos dois alunos Erick Cafferata e Yuta Sakamoto... Ambos tiveram suas próprias ideias. Erick implementa o modo de dispositivo USB para STM32. Yuta migra Embox para placa MAiX-Bit com arquitetura RISC-V. Curiosamente, ambos tinham tarefas de nossa lista em seu e-mail de boas-vindas. Mas, como esperado, após um mergulho mais profundo no projeto, eles formularam melhor suas ideias.
A próxima etapa no plano oficial do programa foi a fase de familiarização, quando os alunos se comunicam mais de perto com a comunidade e continuam estudando o projeto. Como os dois alunos já estavam envolvidos no projeto, foi mais como uma continuação de seu conhecimento para eles. Claro que houve uma diferença. Como já sabíamos quais tópicos os alunos deveriam implementar, oferecemos a eles tarefas próximas às áreas escolhidas.
Como resultado desta fase do programa, foram concluídas várias tarefas preparatórias, o que, a meu ver, permitiu aos alunos uma maior movimentação de acordo com os seus planos para o futuro.
No verão, iniciou-se a principal etapa do programa - a fase de desenvolvimento, a partir da qual deve surgir um novo código. Essa etapa é dividida em três partes, cada uma com duração de um mês. Após cada parte, é realizada a certificação. Espera-se que os alunos trabalhem uniformemente. E com base nos resultados de cada mês, é preciso verificar se os alunos estão no caminho certo.
Na prática, notamos uma atividade diferente dos alunos. Às vezes, parecia até que a atividade era menor do que no estágio preliminar. Descobriu-se que eles haviam iniciado uma sessão ou estavam sobrecarregados com os estudos e não podiam dedicar tempo suficiente para participar do programa. Mas eles trabalharam de forma muito produtiva em outros períodos. Acontece que isso não estava acontecendo apenas em nosso projeto. Como resultado da cúpula de mentores, foi até proposto simplificar as regras e permitir que os alunos e as organizações de mentores acordassem os horários dos alunos.
A comunicação é uma parte importante do desenvolvimento da equipe. Claro, a Embox, como outros projetos de código aberto, tem seus próprios mecanismos de comunicação entre os desenvolvedores. A Embox tem chats por telegrama ( inglês , russo, notícias ) e listas de discussão (inglês (embox-devel [at] googlegroups.com) e russo (embox-ru [at] googlegroups.com)).
Mas, claro, não quero tornar públicas algumas coisas que são discutidas com os alunos. Além disso, os alunos às vezes têm vergonha de fazer perguntas no chat geral. Além disso, GSoC é um programa internacional e, para alguns, existe uma barreira de idioma. Um de nossos alunos escreveu que é difícil para ele se comunicar em inglês. Como resultado, para nos comunicarmos com cada um dos alunos, criamos chats privados nos quais existiam dois mentores: um principal e outro auxiliar. A principal comunicação sobre projetos específicos ocorreu nesses chats. Claro, a comunicação comum ao projeto ocorreu em locais comuns para o projeto ( chat telegramaou github ).
Mas, é claro, a maior parte do programa está focada no desenvolvimento. Nos estágios iniciais, os alunos tiveram que seguir as orientações de terceiros. Um repositório é clonado, um módulo é desenvolvido, um PR é proposto, este PR é revisado, aprovado e então integrado em um projeto. Ou seja, os desenvolvedores de terceiros usam seu próprio repositório. Para verificar as mudanças, você precisa mudar para este repositório. Isso é bom quando se trata de teste apenas, mas quando se trata de um conselho ou de uma única tarefa desenvolvida por várias pessoas, pode aumentar a complexidade. Para evitar isso, ambos os alunos foram adicionados à equipe da Embox e, assim, permitiram que eles criassem ramos no repositório principal. Como resultado, esta acabou sendo a decisão certa, porque na fase final do programa, trabalhamos em estreita colaboração com os alunos,e descobriu-se que os alunos ganharam experiência no desenvolvimento de equipes.
Ambos os alunos concluíram o programa com sucesso. Erick demonstrou a exibição correta do STM32 conectado a um computador usando o utilitário lsusb. E Yuta, usando o utilitário de comando Embox, demonstrou o controle de LED . Claro, Erick também queria adicionar a funcionalidade de um dispositivo, e até desenvolveu ECM-ACM (comporta virtual). E Yuta queria adicionar suporte para o módulo de criptografia. Mas isso foi uma subestimação da complexidade do trabalho proposto. Acho que os resultados obtidos em três meses em uma área tão complexa como programação de sistemas são impressionantes. E o mais importante, os alunos obtiveram uma grande experiência de trabalho em equipe, se familiarizando melhor com o mundo do código aberto e aprimorando significativamente suas habilidades técnicas.
A PS Embox participará no dia 19 de dezembro da sessão blitz online da Conferência Internacional de Desenvolvedores e Usuários de Linux Vacation / Eastern Europe Free Software - LVEE 2020 Online Edition (Lightning).