¡Hola a todos!
Este año Embox participó como organización mentora en el programa GSoC . En este artículo me gustaría hablar de esto, en nuestra opinión, una experiencia muy interesante.
Diré algunas palabras sobre el programa GSoC en sí. Google Summer of Code es el programa global de Google destinado a involucrar a los estudiantes en el mundo del código abierto. Como resultado, los estudiantes han mejorado la calidad del código, la alfabetización tecnológica y las habilidades en los procesos de desarrollo. Estas cualidades se mejoran debido a que los estudiantes están involucrados en proyectos industriales en vivo con procesos de desarrollo suficientemente desarrollados. Esta debería ser la principal motivación para la participación de los estudiantes en este programa. La motivación de las organizaciones de mentores es principalmente el desarrollo y la expansión de la comunidad del proyecto.
Un poco sobre las reglas formales. Solo las comunidades que representan proyectos de código abierto pueden participar en el programa. Un proyecto que tiene un repositorio, pero solo un desarrollador probablemente fracasará, porque necesita dedicar tiempo a los estudiantes. Una organización que quiera participar en el programa debe completar un breve cuestionario, declarar al menos dos administradores y completar una página con las ideas propuestas a los estudiantes. El cuestionario incluye una breve descripción, datos de contacto y un enlace a una página de ideas. Luego viene la selección de organizaciones. Cuando se acepta un proyecto en función de los resultados de la selección, la ficha del proyecto se publica en la página de las organizaciones mentoras del programa y comienza la selección de estudiantes.
La selección de estudiantes es una etapa muy difícil para los mentores. Por primera vez, Embox actuó como organización mentora en el programa GSoC. Y no estábamos preparados para tanta gente que quería participar en el programa. Formalmente, la selección de estudiantes se realiza a partir de ensayos (propuestas), en los que los aspirantes hablan de las tareas que les gustaría completar participando en el proyecto y cómo pretenden hacerlo. Por supuesto, el ensayo contiene datos que generalmente se usan en un currículum, o se pueden solicitar, pero es poco probable que esta información sea suficiente para comprender si el estudiante podrá lograr los resultados deseados. Esta es la principal dificultad para los mentores en esta etapa del programa.
En diferentes proyectos, el conocimiento y la selección se llevan a cabo de diferentes formas. Al discutir temas relacionados con la selección en la lista de correo para los mentores de GSoC, alguien recomendó una entrevista en Skype, alguien para completar las tareas de prueba, alguien para ver un currículum detallado. En Embox, decidimos hacer lo siguiente. Para participar en el programa era necesario, en primer lugar, presentarme escribiendo una breve carta a uno de los mentores del proyecto. En segundo lugar, complete al menos una tarea de la lista en github. Y en tercer lugar, escriba un ensayo oficial en el sitio web del programa.
El primer punto no provocó dificultades especiales. Sí, hubo algunos estudiantes que enviaron ensayos sin siquiera presentarse, pero simplemente no los consideramos. Explicaré un poco el segundo punto. Embox, como todos los proyectos bastante desarrollados, tiene sus propios procesos de desarrollo y, por lo general, los estudiantes simplemente pueden carecer de la práctica de participar en proyectos industriales y distribuidos. Además, Embox es un sistema operativo. Esta suele ser un área nueva en términos de práctica para los estudiantes. Y antes de comenzar a mejorar el proyecto, al menos en algo, debe aprender a compilar, ejecutar, depurar y realizar cambios en el código, comprender los procesos adoptados en el proyecto, el mismo flujo de trabajo de git, etc.
No queríamos hacer tales cosas en la fase activa del programa e intentamos hacerlo en la fase preliminar. Hemos creado tareas muy simples de Good First Issue destinadas a comprender los procesos del proyecto, un conocimiento mínimo de C, la capacidad de leer documentación y buscar información en Internet. De hecho, estábamos seguros de que después de completar dichas tareas, el alumno podrá realizar algunos cambios en el código y preparar un Pull Request.
Sobre esto, se consideraron cumplidos los requisitos previos para la presentación oficial de la solicitud. Pero los estudiantes pueden continuar participando en el proyecto completando otras tareas de la lista en github y sugiriendo sus mejoras y cambios. La única solicitud que tuvimos fue no aceptar el segundo Good First Issue. Queríamos que todos tuvieran las mismas oportunidades y crear una gran cantidad de tareas simples no era una tarea fácil. En todos los demás aspectos, tratamos de ayudar a todos los estudiantes interesados, desde las reglas para configurar relaciones públicas y trabajar con git, hasta explicar la arquitectura y las características del proyecto.
Los estudiantes que siguieron participando en el proyecto siempre que fue posible escribieron muy buenos ensayos. Esto no es sorprendente, porque de esta manera lograron profundizar en el proyecto, sentir la tarea que les gustaría completar y simplemente ganar experiencia.
Muchos de los ensayos de estos estudiantes diferían no solo en la elaboración del plan de trabajo, sino también en los temas. Teníamos una lista de temas sugeridos publicada en nuestra página de ideas, pero inicialmente la consideramos solo como una demostración de posibles direcciones. Y nos alegramos mucho cuando empezaron a ofrecernos sus propios temas.
Para nosotros es importante que el alumno pueda tratar un tema que le interese. Vemos esto como una motivación adicional para los estudiantes. Pero, por supuesto, tu propio tema no es un requisito previo. Teníamos temas muy interesantes, y muchos alumnos, incluso inmersos en el proyecto, querían tratar un tema de la lista propuesta.
Como resultado de este período, se enviaron más de 30 ensayos al proyecto. Hubo al menos cinco muy buenos estudiantes que no solo cumplieron con los requisitos mínimos, sino que también se comunicaron con nosotros en otras tareas, intentaron cumplirlas, ofrecieron sus propias ideas, en general, mostraron interés en el proyecto. Pero lamentablemente, de acuerdo con los resultados de la distribución, solo obtuvimos dos espacios para los estudiantes, casi tuvimos que tirar una moneda. Afortunadamente, como descubrimos un poco más tarde, algunos de los buenos estudiantes pasaron a otros proyectos.
Seleccionamos a dos estudiantes Erick Cafferata y Yuta Sakamoto... Ambos tuvieron sus propias ideas. Erick implementó el modo de dispositivo USB para STM32. Yuta migra Embox a la placa MAiX-Bit con arquitectura RISC-V. Curiosamente, ambos tenían tareas de nuestra lista en su correo electrónico de bienvenida. Pero, como era de esperar, después de una inmersión más profunda en el proyecto, articularon mejor sus ideas.
La siguiente etapa en el plan oficial del programa fue la etapa de conocimiento, cuando los estudiantes se comunican más de cerca con la comunidad y continúan estudiando el proyecto. Dado que ambos estudiantes ya estaban involucrados en el proyecto, fue más como una continuación de su relación para ellos. Por supuesto que hubo una diferencia. Como ya sabíamos qué temas tenían que implementar los alumnos, les ofrecimos tareas cercanas a las áreas elegidas.
Como resultado de esta etapa del programa, se completaron varias tareas preparatorias que, en mi opinión, permitieron a los estudiantes avanzar con mayor éxito de acuerdo con sus planes a futuro.
En verano, comenzó la etapa principal del programa: la etapa de desarrollo, como resultado de la cual debería aparecer un nuevo código. Esta etapa se divide en tres partes, cada una por un mes. Después de cada parte, se realiza la certificación. Se espera que los estudiantes trabajen de manera uniforme. Y en base a los resultados de cada mes, debemos confirmar que los estudiantes van por buen camino.
En la práctica, notamos una actividad diferente de los estudiantes. A veces incluso parecía que la actividad era menor que en la etapa preliminar. Resultó que habían comenzado una sesión o estaban sobrecargados de estudios y no podían dedicar el tiempo suficiente para participar en el programa. Pero trabajaron de manera muy productiva en otros períodos. Resultó que esto estaba sucediendo no solo en nuestro proyecto. Como resultado de la cumbre de mentores, incluso se propuso simplificar las reglas y permitir que los estudiantes y las organizaciones de mentores acuerden el horario de trabajo de los estudiantes.
La comunicación es una parte importante del desarrollo del equipo. Por supuesto, Embox, como otros proyectos de código abierto, tiene sus propios mecanismos de comunicación entre desarrolladores. Embox tiene chats de telegramas ( inglés , ruso, noticias ) y listas de distribución (inglés (embox-devel [at] googlegroups.com) y ruso (embox-ru [at] googlegroups.com)).
Pero, por supuesto, algunas cosas que se discuten con los estudiantes no quieren que se hagan públicas. Además, los estudiantes a veces se sienten avergonzados de hacer preguntas en el chat general. Además, GSoC es un programa internacional y para algunos existe una barrera del idioma. Uno de nuestros estudiantes escribió que le resultaba difícil comunicarse en inglés. Como resultado, para comunicarnos con cada uno de los alumnos, creamos chats privados en los que había dos mentores: uno principal y otro auxiliar. La principal comunicación sobre proyectos concretos tuvo lugar en estos chats. Por supuesto, la comunicación común al proyecto se llevó a cabo en lugares comunes para el proyecto ( telegram chato github ).
Pero, por supuesto, la mayor parte del programa se centra en el desarrollo. En las primeras etapas, los estudiantes tenían que seguir pautas de terceros. Se clona un repositorio, se desarrolla un módulo, se ofrece un RP, este RP se revisa, aprueba y luego se fusiona en un proyecto. Es decir, los desarrolladores de terceros utilizan su propio repositorio. Para verificar los cambios, debe cambiar a este repositorio. Esto está bien cuando se trata solo de pruebas, pero cuando se trata de un consejo o una sola tarea desarrollada por varias personas, puede agregar complejidad. Para evitar esto, ambos estudiantes se agregaron al equipo de Embox y así les permitieron crear ramas en el repositorio principal. Como resultado, resultó ser la decisión correcta, porque en la etapa final del programa trabajamos bastante de cerca con los estudiantes,y resultó que los estudiantes adquirieron experiencia en el desarrollo de equipos.
Ambos estudiantes completaron el programa con éxito. Erick demostró la visualización correcta de STM32 conectado a una computadora usando la utilidad lsusb. Y Yuta demostró el control de LED utilizando la utilidad de comando Embox . Por supuesto, Erick también quiso agregar la funcionalidad de algún dispositivo, e incluso desarrolló un ECM-ACM (comport virtual). Y Yuta quería agregar soporte para el módulo de encriptación. Pero esto fue una subestimación de la complejidad del trabajo propuesto. Encuentro que los resultados obtenidos en tres meses en un área tan compleja como la programación de sistemas son impresionantes. Y lo más importante, los estudiantes obtuvieron una gran experiencia de trabajo en equipo, se familiarizaron mejor con el mundo del código abierto y mejoraron significativamente sus habilidades técnicas.
PS Embox participará en la sesión relámpago en línea de la Conferencia Internacional de Desarrolladores y Usuarios de Software Libre Linux Vacation / Eastern Europe - LVEE 2020 Online Edition (Lightning) el 19 de diciembre .