Confier des tâches de développement de ZdS comme projet à des étudiants-ingénieurs

Bonjour à tous,

Le sujet a été discuté lors de la dernière réunion des dev’s de ZdS, et j’ai un peu traîné pour créer ce sujet (les vacances m’ont un peu éloigné d’Internet).

J’ai un diplôme d’ingénieur en informatique de l'ENSEIRB-MATMECA, école d’ingénieurs qui possède plusieurs filières, dont l’informatique. Cette école recrute à BAC+2, majoritairement des étudiants de classes préparatoires, mais aussi quelques étudiants sortant de DUT, licence, etc. En deuxième année (de l’école, donc équivalent à l’année du M1 à la fac), les étudiants ont un Projet au Fil de l’Année (PFA).

Projet au Fil de l’Année

Chaque groupe de 6 étudiants réalise de novembre à mai un projet correspondant aux besoins d’un "client". Le terme de client fait référence ici à la simulation d’une relation client/prestataire où un client vient voir un prestataire en informatique pour qu’il lui réalise un logiciel, site web, … bref qu’il code quelque chose. Généralement, on trouve des projets d’enseignants de l’école, des contributions à des logiciels utilisés pour les activités de recherche des enseignants-chercheurs, mais aussi des projets n’émanant pas de l’équipe pédagogique. Chaque étudiant choisit le projet sur lequel il souhaite travailler (les étudiants ayant choisi le même projet seront dans le même groupe). Pendant une première période, le groupe rencontre le client et rédige un dossier de spécifications : la liste des besoins recueillis auprès du client, la liste des tâches à réaliser concrètement dans la deuxième période du PFA. Les étudiants peuvent consacrer quelques (2, 4 ?) heures au PFA par semaine.

Le client n’a rien à payer à l’école ou aux étudiants pour la réalisation du projet. Mais il ne faut pas oublier que c’est un projet d’étudiants et non de professionnels : il arrive (malheureusement) que certains PFA ne se déroulent pas bien (le but du PFA est aussi d’expérimenter le travail d’équipe, l’organisation d’un projet, la gestion du temps, …) et/ou que le travail réalisé ne soit pas exploitable… Cela dit, ça reste des cas à la marge.

Un PFA sur Zeste de Savoir

J’ai proposé à l’équipe de développement de ZdS, lors de la dernière réunion, de soumettre un projet qui contiendrait quelques tâches de développement du site de Zeste de Savoir, voire de zMarkdown. Plutôt le genre de tâches un minimum conséquentes, pour lesquelles quelques heures de développeurs bénévoles en soirée ou le week-end ne suffisent pas .

Quelques idées de tâches à confier aux étudiants ont rapidement émergé :

• Migration de zmd vers micromark ;
• Évolution de l’interface de rédaction vers un système unifié (sans séparation entre les parties, chapitres et sections) et temps-réel ;
• Mise en place les évolutions du groupe de travail « Organisation des publications » ;
• Mise en place des parcours ;
• Nouvel éditeur ;
• Amélioration de la recherche (mise à jour de ElasticSearch, passage à un autre outil ?) ;
• Quizz et sondages.

Chaque idée méritant du contexte et une explication de ce qui serait attendu, un document Framapad contient ces éléments. Le but de ce document est aussi d’écrire collaborativement le sujet du projet que les étudiants consulteront pour choisir (ou pas !) de travailler sur ZdS.

Bien-sûr, il y a là trop de tâches pour que les étudiants puissent toutes les réaliser sur le temps du PFA. L’idée serait de les laisser choisir sur quelles tâches ils souhaitent travailler.

Déroulement du PFA ZdS

L’idée de ce PFA serait aussi de confronter les étudiants au monde du libre et notamment des contributions aux logiciels libres : utilisation de Git (et GitHub dans notre cas), revues de code, relations et échanges avec les développeurs amonts (l’équipe de dev de ZdS, ici).

Pour cela, l’idée serait commencer par faire contribuer les étudiants comme n’importe quel nouveau contributeur à ZdS : chaque étudiant du groupe met en place l’environnement de développement, réalise une première PR qui clôt un ticket (pré-mâché, par exemple ; c’est surtout pour prendre en main le mécanisme de PR de GitHub et se familiariser avec notre façon de travailler). Les étudiants seront bien-sûr invités à rejoindre le Discord de ZdS et poser leurs questions sur le canal dédié, comme n’importe quel contributeur. Cette première étape peut se faire dès le début du PFA, en parallèle de l’élaboration du document de spécifications.

Pour réaliser le document de spécifications, le groupe échangera (Discord, n’importe quel système de visio, …) avec l’équipe de dév pour avoir plus de détails sur ce qui est demandé pour chaque tâche.

Une fois le document de spécifications réalisé (les étudiants auront donc choisi les tâches qu’ils souhaitent réaliser), le développement se passe comme pour n’importe quel contributeur : les étudiants codent, posent des questions si besoin, font des PRs, obtiennent des commentaires sur les PRs, etc.

À la fin du PFA, les étudiants doivent rédiger un rapport présentant le travail réalisé et une présentation orale a également lieu.

Du côté de l’équipe de dev de ZdS

Je n’ai pas encore de date, mais le sujet du PFA que l’on souhaite proposer devra probablement être envoyé en septembre. D’ici là, il faut :

• se mettre d’accord sur les tâches à proposer, et leur contenu ;
• pour chaque tâche, identifier un membre de l’équipe de dev qui pourra suivre la progression des étudiants sur cette tâches, notamment répondre aux questions, échanger avec eux, faire de la QA sur leurs PRs, etc. En gros : être réactif et disponible (potentiellement plus que ce que demande une contribution bénévole à ZdS) ;
• rédiger le sujet final à envoyer : rédiger l’introduction (présentation de Zeste de Savoir, les différentes briques techniques), rédiger le déroulement le PFA (grosso modo la partie ci-dessus) et peut-être raccourcir un peu les descriptions de chaque tâche (ce qui est déjà rédigé me paraît assez long, il suffit que les étudiants aient un aperçu de ce qu’il y a à faire, la version détaillée est cependant bien pour se mettre d’accord entre nous ; on discutera avec les étudiants des détails lors de la phase de rédaction du document de spécifications)

Ayant fait un PFA en tant qu’étudiant, ayant été client pour un PFA lors de ma thèse, et connaissant bien l’école et l’équipe pédagogique, je me propose naturellement comme client "officiel", pour faire l’interface entre le responsable des PFA et l’équipe de dev de ZdS (bref, ce sera mon nom et mon adresse mail dans leur liste de clients de PFA).

Ce sujet est là pour discuter de ce projet. N’hésitez pas à poser vos questions (elles étaient nombreuses lors de la réunion des dev’s !), proposer des tâches ou simplement discuter de celles qui ont déjà été évoquées.

Je trouve l’idée excellente, et qui pourrait apporter beaucoup de plus à ZdS si ça pouvait se concrétiser !

Un demi-HS sur ce point précis :

Amélioration de la recherche (mise à jour de ElasticSearch, passage à un autre outil ?) ;

Pour avoir pas mal joué avec des outils d’indexation (ElasticSearch, Apache Solr, Lucene…) : l’outil en lui-même (ElasticSearch) est parfaitement capable de nous fournir des résultats très pertinents, ou même de gérer des fonctionnalités existantes ou futures aujourd’hui en BDD (je pense à des liens entre tutos par exemple). Évidemment, il faut réécrire le système d’indexation actuel pour des raisons techniques.

Mon propos est surtout que changer d’outil ne va pas magiquement renvoyer des résultats plus pertinents que ce qu’on a actuellement. Pourquoi ? Parce que la difficulté de la tâche « obtenir des résultats pertinents » n’est pas dans l’outil, aucun outil n’est magique de ce point de vue. La difficulté, c’est de paramétrer l’outil pour qu’il puisse comprendre ce qu’on veut lui faire indexer et sortir des résultats pertinents. Ça implique de jouer avec les outils d’analyse et de pré-traitement intégrés à tout bon moteur d’indexation de langage naturel qui se respecte : traitement en fonction de la langue, liste de mots-outils à ignorer, poids relatifs des différents champs à indexer (titre, sous-titre, tags, catégories, contenu, etc), définition de synonymes… le cas de ZdS a pour difficulté supplémentaire qu’on a pas mal de code dans les contenus, qu’il faut gérer aussi.

Concrètement ça implique beaucoup d’essais-erreurs sur un jeu de données réaliste (concrètement, une copie des vraies données) et d’utiliser un connecteur Django - outil d’indexation qui permette ces subtilités. Sur ce dernier point, j’avais regardé rapidement ce qui existait, et j’ai eu l’impression au contraire qu’on trouvait surtout des connecteurs qui essaient de masquer la complexité de ce genre d’outil – ce qui est une fausse bonne idée, puisque par conséquence ça ne permet plus d’avoir des résultats pertinents.

Et donc : quel que soit l’outil choisi pour remplacer l’existant, il faut qu’il permette un paramétrage fin, une compréhension du français, et possède un connecteur avec Django qui ne rende pas ce paramétrage trop complexe.

Je vais faire mon rabat joie mais lorsque je me suis essayé à vouloir me lancer dans le code du zds, j’ai eu assez peu d’aide (y compris sur discord)
Je peux comprendre que les devs soient occupé mais ici je pense qu’il est nécessaire que quelqu’un soit vraiment disponible car ce genre de projet est souvent une grosse part de la note finale de l’élève

J’ai bien lu ce passage

Mais je me permets d’attirer l’attention la dessus

Je vais faire mon rabat joie mais lorsque je me suis essayé à vouloir me lancer dans le code du zds, j’ai eu assez peu d’aide (y compris sur discord)
Je peux comprendre que les devs soient occupé mais ici je pense qu’il est nécessaire que quelqu’un soit vraiment disponible car ce genre de projet est souvent une grosse part de la note finale de l’élève

Merci de ton retour ! Je suis désolé que tu n’aies pas reçu assez d’aide d’après toi. :/ J’aimerais bien en savoir plus sur les situations où tu aurais aimé être plus accompagné, si jamais tu as l’envie et le temps d’échanger là-dessus ! Je n’ai pas réussi à retrouver les messages sur Discord et sans eux il est difficile d’identifier ce qui n’a pas été. Bref, n’hésites pas à m’envoyer un message privé ou à me mentionner sur Discord pour qu’on en discute ! (Je pense qu’en parler plus en détails dans ce sujet serait hors-sujet.)

• Migration de zmd vers micromark ;

Oh là là.
C’est un travail vraiment conséquent. Je veux dire vraiment. Clairement pas au même niveau que de mettre à jour Elastic Search.

Pas de soucis, je continue ici car cela ne me semble pas hors sujet. Le plus gros problème étant justement un manque de disponibilité de l’équipe dev: je me connectais aux heures de bureaux et un simple "bonjour" pouvait avoir une réponse que 1 ou 2 heures plus tard.
Je comprend tout à fait cela au vu de la nature du projet mais les étudiants vont avoir un peu près les mêmes heures de productivités que j’avais d’où ma mise en garde
Après ce n’est peut être pas un problème; je me souviens que lors de tel projet, mes "clients" (qui étaient un professeur) faisait exprès de ne pas être réactif car un vrai client peut n’avoir que peu de temps à consacrer à un projet.

Les 2 autre soucis sont hors sujet cette fois. On peut en discuter en mp si tu le souhaites mais pour résumer:

• j’évolue sur Windows or personne n’avait cette conf à l’époque
• difficile de choisir les premiers tickets à traiter : il y a bien ceux taguer "facile" mais après on est un peu perdu

Attendre une réponse aussi rapide me paraît déraisonnable quoi qu’il arrive. Personne n’a l’obligation de se plier à ta fenêtre de productivité.

Si tu dis juste "bonjour" sans poser de question, ne t’attends pas à avoir de réponse rapide (ou même de réponse du tout dans un cadre public comme Discord). Sur un moyen de communication asynchrone, ce n’est pas dans les us et coutumes. Dans certaines cultures, c’est attendu qu’on fasse des cérémonies avant de se poser la vraie question, mais ailleurs on préfère "don’t ask to ask", ce qui est plus efficace.

Pour ce qui est de Windows, le souci est légitime vu le peu d’utilisateur chez nous (et leur expérience, ils savent se débrouiller). Je pense que pour des étudiants en école d’ingé dans un cadre non-bénévole, on peut exiger qu’ils soient capables d’être pragmatiques et utiliser efficacement WSL ou une VM Linux.

Du coup, les points que tu lèves ne m’inquiètent pas outre mesure.

Dans mon cas, je suis d’accord mais les élèves s’attendent peut être à un peu plus de réactivité à certaines étapes du projet

Oui j’avais dis que c’était HS (et je partage ton opinion), je répondais uniquement succinctement à la question de Situphen

Ok, pas de soucis. Dans ce cas, je ne vois que du positif

Dans certaines cultures, c’est attendu qu’on face des cérémonies avant de se poser la vraie question, mais ailleurs on préfère "don’t ask to ask", ce qui est plus efficace.

Il me parait important de préciser explicitement que, dans ce cadre, on préfère le « don’t ask to ask ». Ça éviterai des incompréhensions faciles à lever – surtout si les étudiant qu’on a sont d’une culture qui apprécie les cérémonials.

(PS : c’est un problème qu’on avait eu dans un de mes boulots, où les Français ne comprenaient pas pourquoi les Marocains commençaient toutes les conversations par des politesses même si on s’était parlé 10 minutes avant, et où les Marocains ne comprenaient pas pourquoi les Français étaient aussi impolis, pressés et désagréables – personne ne s’était posé la question d’une différence culturelle. Les problèmes ont à peu près disparus quand on en a parlé).

En fait le vrai intitulé serait certainement un truc du genre « Migration partielle de zmd vers micromark », on ne s’attend pas vraiment à ce que tout soit fini, mais ça a sans doute un intérêt pour eux (et nous) s’ils portent quelques plugins, ça leur permettrait de se plonger dans le nouveau système (et l’ancien) qui est assez intéressant dans son fonctionnement.

+1, d’autant plus qu’il faut bien prendre en compte que la migration vers micromark est, au vue de la structure de zmd, découpée en plein de petits bouts, certains étant plus courts et simples que d’autres. Faire un peu avancer le schmilblick, quitte à se concentrer sur des plugins pas trop complexes, ne me semble pas insurmontable, mais bien sûr on ne parle pas de tout finir.

Ok, ça me semble beaucoup plus modeste et même intéressant.

Dans ce cas, très franchement, je pense que c’est même l’idéal. Ces plugin sont très bien testés. L’objectif est donc déjà correctement défini. Normalement, on ne se sert pas de tests comme spécifications mais ici particulièrement ça me semble adapté. Étant une mise à jours, le passage des tests de non régressions est l’un des contraintes.

C’est un travail vraiment conséquent. Je veux dire vraiment. Clairement pas au même niveau que de mettre à jour Elastic Search.

À noter que ce n’est pas que "mettre à jour". Elastic Search a beaucoup changé entre la dernière version et celle qu’on utilise actuellement et il faut tout migrer, avec des changements assez extensifs.

Dans le cas d’ElasticSearch, je confirme, c’est pas une mise à jour mais une réécriture complète – la structure d’index qu’on utilise n’est plus possible, et c’est la base de tout.

Très très très très très bonne idée

Bon, j’appuie évidement @SpaceFox pour ElasticSearch sur le "c’est pas l’outil le problème, c’est la config", même si on est d’accord qu’il faudrait évidement le mettre à jour. Il n’y a pas eu un drama autour de la licence d’Elastic, aussi?

Plus sérieusement, je me permet tout de même de rebondir sur la remarque de @DonKnacki, qui pour moi soulève un "problème" auquel il faudrait être attentif. Les devs’ de ZdS sont principalement bénévoles et travaillent principalement durant leur temps libre (si j’avais un peu de temps, je ferais bien un article sur le sujet en poutrant un peu les API de github, mais, hélas …). Par contre, un étudiant travaillera probablement dans les "heures de bureau", vu que (j’imagine) ils ont des heures allouées à ça dans leur programme de cours. Il faut donc s’assurer que quelqu’un soit tout de même "disponible" pour ça, surtout au début.

Je dis ça sans bien connaitre le système, donc @philippemilink, n’hésite pas à me corriger

Pour ce que tu me demandes, je pense que la personne qui a eu l’idée de ça serait mieux placée pour développer le paragraphe. Je ne sais pas comment transformer ça en sujet clair.

Pour les quizz, j’ai maj ma PR. on peut d’ailleurs dire que je suis volontaire pour accompagner les étudiants dans ce travail.

Bonjour tout le monde,

J’ai rédigé la partie "Organisation des publications" et j’ai fait une relecture générale : https://semestriel.framapad.org/p/sujet-pfa-zds-9wx3. J’ai supprimé pas mal de choses, pour raccourcir et éviter les redites (désolé pour ceux qui avaient passé du temps à l’écrire initialement).

Ça me semble pas mal, je vous laisse jusqu’à lundi matin pour relire et apporter éventuellement des corrections.

Relu pour ma part, j’ai dédupliqué les "mise à jour" qui étaient vraiment nombreux à mon goût (sans doute de ma faute au départ ).

Ça me va, globalement.

Cependant, j’ai de très grosses réserves sur la partie Mise en place des évolutions du groupe de travail « Organisation des publications ». Ça me paraît très hasardeux de lancer des étudiants non familiers avec la base de code dessus sans plus de travail préparatoire de notre part, qui n’a aucune garantie d’être fait à temps. Je pense qu’il faudrait simplement supprimer cette partie du document.