Expérience Embox en tant qu'organisation de mentorat dans le programme GSoC2020

imageBonjour à tous!



Cette année, Embox a participé en tant qu'organisation de mentorat au programme GSoC . Dans cet article, je voudrais parler de cela, à notre avis, une expérience très intéressante.



Je dirai quelques mots sur le programme GSoC lui-même. Google Summer of Code est le programme mondial de Google visant à impliquer les étudiants dans le monde open source. En conséquence, les étudiants ont amélioré la qualité du code, les connaissances technologiques et les compétences dans les processus de développement. Ces qualités sont renforcées par le fait que les étudiants sont impliqués dans des projets industriels en direct avec des processus de développement suffisamment développés. Cela devrait être la principale motivation de la participation des étudiants à ce programme. La motivation des organisations de mentorat est principalement le développement et l'expansion de la communauté du projet.



Un peu sur les règles formelles. Seules les communautés représentant des projets open source sont autorisées à participer au programme. Un projet qui a un référentiel, mais un seul développeur échouera probablement, car vous devez consacrer du temps aux étudiants. Une organisation qui souhaite participer au programme doit remplir un court questionnaire, déclarer au moins deux administrateurs et remplir une page avec des idées proposées aux étudiants. Le questionnaire comprend une brève description, des coordonnées et un lien vers une page d'idées. Vient ensuite la sélection des organisations. Lorsqu'un projet est accepté en fonction des résultats de la sélection, la fiche de projet est publiée sur la page des organismes de mentorat du programme et la sélection des étudiants commence.



La sélection des étudiants est une étape très difficile pour les mentors. Pour la première fois, Embox a agi en tant qu'organisation de mentorat pour le programme GSoC. Et nous n'étions pas préparés pour tant de personnes qui voulaient participer au programme. Formellement, la sélection des étudiants est basée sur des essais (propositions), dans lesquels les candidats parlent des tâches qu'ils aimeraient accomplir en participant au projet et comment ils ont l'intention de le faire. Bien sûr, l'essai contient des données qui sont généralement utilisées dans un curriculum vitae, ou vous pouvez le demander, mais ces informations ne seront probablement pas suffisantes pour comprendre si l'étudiant sera ou non en mesure d'obtenir les résultats souhaités. C'est la principale difficulté pour les mentors à ce stade du programme.



Dans différents projets, la connaissance et la sélection se font de différentes manières. Lors de la discussion de problèmes liés à la sélection dans la liste de diffusion pour les mentors GSoC, quelqu'un a recommandé une entrevue sur Skype, quelqu'un pour effectuer des tâches de test, quelqu'un pour voir un CV détaillé. Chez Embox, nous avons décidé de faire ce qui suit. Pour participer au programme, il fallait, dans un premier temps, se présenter en écrivant une courte lettre à l'un des mentors du projet. Deuxièmement, effectuez au moins une tâche de la liste sur github. Et troisièmement, rédigez un essai officiel sur le site Web du programme.



Le premier point n'a pas posé de difficultés particulières. Oui, certains étudiants ont soumis leurs dissertations sans même se présenter, mais nous ne les avons tout simplement pas considérés. J'expliquerai un peu le deuxième point. Embox, comme tous les projets assez développés, a ses propres processus de développement et les étudiants peuvent généralement ne pas avoir l'habitude de participer à des projets industriels et distribués. De plus, Embox est un système d'exploitation. Il s'agit généralement d'un nouveau domaine en termes de pratique pour les étudiants. Et avant de commencer à améliorer le projet au moins quelque chose, vous devez apprendre à créer, exécuter, déboguer et apporter des modifications au code, comprendre les processus adoptés dans le projet, le même flux de travail git, etc.



Nous ne voulions pas faire de telles choses dans la phase active du programme, et nous avons essayé de le faire au stade préliminaire. Nous avons créé des tâches très simples Good First Issue visant à comprendre les processus du projet, une connaissance minimale de C, la capacité de lire la documentation et de rechercher des informations sur Internet. En fait, nous étions convaincus qu'après avoir terminé ces tâches, l'étudiant sera en mesure d'apporter des modifications au code et de préparer une Pull Request.



À ce stade, les conditions préalables au dépôt officiel de la demande ont été considérées comme remplies. Mais les étudiants pouvaient continuer à participer au projet en accomplissant d'autres tâches de la liste sur github et en suggérant leurs améliorations et modifications. La seule demande que nous avions était de ne pas prendre le deuxième bon premier numéro. Nous voulions que tout le monde ait une chance égale, et la création de nombreuses tâches simples s'est avérée une tâche ardue. À tous autres égards, nous avons essayé d'aider tous les étudiants intéressés, depuis les règles de mise en place des relations publiques et de travail avec git, jusqu'à l'explication de l'architecture et des fonctionnalités du projet.



Les étudiants qui ont continué à participer au projet autant que possible ont écrit de très bons essais. Ce n'est pas surprenant, car de cette manière, ils ont réussi à plonger plus profondément dans le projet, à ressentir la tâche qu'ils aimeraient accomplir et à acquérir simplement de l'expérience.



Bon nombre des essais de ces étudiants différaient non seulement dans l'élaboration du plan de travail, mais aussi dans les sujets. Nous avions publié une liste de sujets suggérés sur notre page d'idées, mais nous ne l'avons d'abord considérée que comme une démonstration des directions possibles. Et nous avons été très heureux quand ils ont commencé à nous proposer leurs propres thèmes.



Il est important pour nous que l'élève puisse traiter un sujet qui l'intéresse. Nous voyons cela comme une motivation supplémentaire pour les étudiants. Mais, bien sûr, votre propre thème n'est pas une condition préalable. Nous avions des sujets très intéressants, et de nombreux étudiants, même immergés dans le projet, voulaient traiter un sujet de la liste proposée.



À la suite de cette période, plus de 30 essais ont été soumis au projet. Il y avait au moins cinq très bons étudiants qui non seulement répondaient aux exigences minimales, mais qui communiquaient également avec nous sur d'autres tâches, essayaient de les remplir, proposaient leurs propres idées, en général, montraient de l'intérêt pour le projet. Mais malheureusement, suite à la distribution, nous n'avons eu que deux créneaux pour les étudiants, nous avons failli jeter une pièce. Heureusement, comme nous l'avons découvert un peu plus tard, certains des bons étudiants sont allés à d'autres projets.



Nous avons sélectionné deux étudiants Erick Cafferata et Yuta Sakamoto... Les deux ont proposé leurs propres idées. Erick implémente le mode périphérique USB pour STM32. Yuta migre Embox vers la carte MAiX-Bit avec l'architecture RISC-V. Fait intéressant, les deux avaient des tâches de notre liste dans leur e-mail de bienvenue. Mais, comme prévu, après une plongée plus profonde dans le projet, ils ont mieux formulé leurs idées.



L'étape suivante du plan officiel du programme était l'étape de la connaissance, lorsque les étudiants communiquent plus étroitement avec la communauté et continuent d'étudier le projet. Étant donné que les deux étudiants étaient déjà impliqués dans le projet, cela ressemblait davantage à une continuation de leur connaissance pour eux. Bien sûr, il y avait une différence. Comme nous savions déjà quels sujets les étudiants devaient mettre en œuvre, nous leur avons proposé des tâches proches des domaines choisis.



À la suite de cette étape du programme, plusieurs tâches préparatoires ont été accomplies, ce qui, à mon avis, a permis aux étudiants de se déplacer avec plus de succès selon leurs plans à l'avenir.



En été, la phase principale du programme a commencé - la phase de développement, à la suite de laquelle un nouveau code devrait apparaître. Cette étape est divisée en trois parties, chacune pendant un mois. Après chaque partie, une certification est effectuée. Les étudiants doivent travailler de manière uniforme. Et sur la base des résultats de chaque mois, nous devons confirmer que les étudiants sont sur la bonne voie.



Dans la pratique, nous avons remarqué une activité étudiante différente. Parfois, il semblait même que l'activité était plus faible qu'au stade préliminaire. Il s'est avéré qu'ils avaient commencé une session ou étaient surchargés d'études et ne pouvaient pas consacrer suffisamment de temps pour participer au programme. Mais ils ont travaillé de manière très productive à d'autres périodes. Il s'est avéré que cela ne se produisait pas seulement dans notre projet. À la suite du sommet des mentors, il a même été proposé de simplifier les règles et de permettre aux étudiants et aux organismes de mentorat de s'entendre sur l'horaire de travail des étudiants.



La communication est une partie importante du développement de l'équipe. Bien entendu, Embox, comme d'autres projets open source, dispose de ses propres mécanismes de communication entre développeurs. Embox a des discussions par télégramme ( anglais , russe, news ) et listes de diffusion (anglais (embox-devel [at] googlegroups.com) et russe (embox-ru [at] googlegroups.com)).



Mais, bien sûr, je ne veux pas rendre public certaines choses dont on discute avec les étudiants. De plus, les étudiants sont parfois gênés de poser des questions dans le chat général. De plus, GSoC est un programme international et pour certains il existe une barrière linguistique. Un de nos étudiants a écrit qu'il lui était difficile de communiquer en anglais. En conséquence, pour communiquer avec chacun des étudiants, nous avons créé des chats privés, dans lesquels il y avait deux mentors: un principal et un aidant. La communication principale sur des projets spécifiques a eu lieu dans ces chats. Bien entendu, la communication commune au projet a eu lieu dans des lieux communs pour le projet ( chat télégrammeou github ).



Mais, bien sûr, l'essentiel du programme est axé sur le développement. Au début, les étudiants devaient suivre des directives tierces. Un référentiel est cloné, un module est développé, un PR est proposé, ce PR est revu, approuvé puis fusionné dans un projet. Autrement dit, les développeurs tiers utilisent leur propre référentiel. Afin de vérifier les modifications, vous devez basculer vers ce référentiel. C'est bien lorsqu'il s'agit de tester uniquement, mais lorsqu'il s'agit d'un conseil ou d'une seule tâche développée par plusieurs personnes, cela peut ajouter de la complexité. Pour éviter cela, les deux étudiants ont été ajoutés à l'équipe Embox et leur ont ainsi permis de créer des branches dans le référentiel principal. En conséquence, cela s'est avéré être la bonne décision, car au stade final du programme, nous avons travaillé en étroite collaboration avec les étudiants,et il s'est avéré que les étudiants ont acquis de l'expérience dans le développement d'équipe.



Les deux étudiants ont terminé le programme avec succès. Erick a démontré l'affichage correct de STM32 connecté à l'ordinateur à l'aide de l'utilitaire lsusb. Et Yuta a démontré le contrôle des LED à l'aide de l'utilitaire de commande Embox . Bien sûr, Erick voulait également ajouter des fonctionnalités à certains appareils, et a même développé ECM-ACM (port virtuel). Et Yuta voulait ajouter la prise en charge du module de cryptage. Mais c'était une sous-estimation de la complexité du travail proposé. Je trouve que les résultats obtenus en trois mois dans un domaine aussi complexe que la programmation système sont impressionnants. Et surtout, les étudiants ont acquis une grande expérience du travail d'équipe, se sont mieux familiarisés avec le monde de l'open source et ont considérablement amélioré leurs compétences techniques.



PS Embox participera à la session blitz en ligne de la Conférence internationale des développeurs et utilisateurs de logiciels libres Linux Vacation / Eastern Europe - LVEE 2020 Online Edition (Lightning) le 19 décembre .



All Articles