-
Notifications
You must be signed in to change notification settings - Fork 14
Charte du groupe de référents R
L’objectif de la présente charte est de formaliser le fonctionnement du GRR pour que ses membres partagent son principe de fonctionnement. Elle facilite également l’intégration de nouveaux référents.
Le Groupe de Référents R (GRR) a pour mission de construire et de maintenir le parcours de formations en langage R de traitement de la donnée du pôle ministériel. Les différents modules de formation sont destinés à accompagner les agents dans leur montée en compétences en R pour collecter, exploiter, diffuser et valoriser la donnée. Ces modules s’adressent en priorité aux grands débutants en R pour les deux modules socles, et aux débutants dans le domaine des modules à la carte. Enfin, ces formations encouragent les utilisateurs à adopter les bonnes pratiques de gestion de projet, de style de codage, de maintenabilité, d’usage des packages recommandés, dans une optique d’harmonisation des pratiques. Ainsi en proposant un corpus de compétences de référence partagé à tous les R-istes du pôle ministériel, la collaboration et l’entraide seront facilités et les travaux de connaissance menés seront fiabilisés et pérennisés.
Le GRR est composé d’une dizaine d’agents des services centraux du ministère et déconcentrés (Dreal/Deal/DDT). Il est co-animé par le BUN et la DREAL des Pays de la Loire dans le cadre du pôle national de service d’Appui à la Connaissance territoriale Reproductible (ACTeR). Leur engagement respectif concerne :
- pour le BUN, d’assurer la maîtrise d’ouvrage des formations déployées par les CVRH, de recenser les besoins du SDES (contenu des formations et volume de formés)
- pour le pôle ACTeR, de recueillir les besoins des utilisateurs des services déconcentrés (enquête, ateliers…).
Le BUN et le pôle :
- organisent deux réunions par an
- coordonnent les activités du GRR et celles du CVRH. Notamment, ils le convient le cas échéant aux réunions des GRR et organisent les échanges.
Lors du déploiement d’un nouveau module, une à deux réunions spécifiques de validation peuvent être nécessaires dans l’année.
Les membres du GRR adoptent des principes pédagogiques communs pour garantir la cohérence et l’efficacité des formations :
- Cible prioritaire : le parcours de formation est principalement destiné aux personnes les moins autonomes dans l’apprentissage de R.
- Simplicité : l’accent est mis sur la simplicité pour favoriser l’apprentissage progressif et éviter de submerger les apprenants avec des concepts trop complexes d’un seul coup.
- Packages utilisés : afin de faciliter la collaboration et l’apprentissage, le groupe s’accorde à limiter le nombre de packages enseignés. Le tidyverse est privilégié dans l’ensemble des formations, sauf dans les cas de traitement de Big Data, où d’autres outils spécifiques seront introduits.
- Évolution des supports : les supports de formation doivent être régulièrement mis à jour pour suivre les évolutions des packages, des bonnes pratiques et des besoins des apprenants.
- Durée des formations : les supports sont calibrés pour des formations de 2 à 3 jours maximum.
- Autoformation : les supports sont conçus pour être exploitables en autonomie : le contenu est autoportant et les exercices sont réalisables via le package {savoirfR}.
Chaque membre du GRR s’engage à :
- contribuer à la définition des objectifs pédagogiques de chaque module ;
- contribuer à la création des supports de formation selon ses disponibilités et en respectant les principes pédagogiques et les objectifs définis par le groupe ;
- contribuer à la révision des supports produits pour garantir leur fraîcheur et pertinence ;
- prendre en compte les retours des utilisateurs pour améliorer les ressources ;
- participer activement aux discussions pour valider ou enrichir les initiatives proposées par d’autres membres.
Le fonctionnement du GRR s’inspire de celui du développement open-source dans l’idée d’en maximiser l’efficacité et d’en garantir la collégialité.
Prise de décision au sein du GRR Les décisions les plus significatives sont prises collectivement, que ce soit via des discussions en réunion ou des consultations asynchrones. Pour cela, deux principaux canaux sont utilisés :
- Tchap pour les échanges informels et les discussions rapides
- GitHub pour formaliser les actions :
- Tickets : décomposent la production d’un nouveau support en petites parties, remonter les problèmes ou besoins d’amélioration des supports.
- Kanban : organise visuellement les tâches à accomplir, en cours, ou finalisées.
- Discussions : sert aux échanges (idées, orientations plus stratégiques).
Autonomie Chaque membre est encouragé à prendre des initiatives concernant l’amélioration des supports dans le cadre des objectifs et priorités définis par le groupe. Avant d’être intégré dans la branche principale, les évolutions doivent être soumises pour validation à au moins un référent du groupe qui n’a pas pris part à la rédaction. Les modifications de type corrections typographiques ou mise à jour de la liste des référents, peuvent s’affranchir de ce processus. En cas de divergences, des discussions collégiales seront menées pour faire émerger un consensus. Les tâches sont assignées en réunion ou auto-assignées selon les compétences et les disponibilités.
Transparence
Toutes les informations (décisions, tâches, avancement) sont partagées ouvertement avec le groupe, principalement via Tchap et GitHub. Cela assure une bonne visibilité et permet à chacun de s’impliquer selon ses disponibilités.
Fondamentaux Pour chaque module, le dépôt Github contient le code source du support de formation. Les exercices sont idéalement mis à disposition dans le package {savoirfR}. L’intégration continue assure la diffusion du support html compilé tout en apportant des garanties d’exécution du code présenté aux stagiaires. Il faut chercher à factoriser les parties communes à différents dépôts.
Maintenance des supports La maintenance des supports existants est essentielle pour garantir la qualité et la pertinence des formations. Le processus de maintenance est le suivant :
- Demandes de modifications : Les stagiaires ou formateurs peuvent soumettre des demandes de modifications en créant un ticket sur le dépôt GitHub du parcours de formation.
- Proposition de modifications : Un volontaire du GRR se charge de la modification en proposant une Merge Request (MR) qu’il soumet à un autre membre pour validation.
- Discussion des modifications : Si aucune personne ne se propose pour réaliser la modification ou si celle-ci n’est pas triviale, elle sera discutée collectivement dans le ticket, voire lors de la prochaine réunion du GRR.
Conception de nouveaux modules La création de nouveaux modules de formation suit un processus rigoureux afin de répondre aux besoins des services et de maintenir la cohérence pédagogique du parcours. Ce processus comprend les étapes suivantes :
- Besoins : Sur la base du recensement des besoins par ACTeR auprès du comité des utilisateurs R en service déconcentré et de ceux du SDES remontés par le BUN, les besoins de nouveaux modules sont discutés au sein du GRR.
- Définition des objectifs pédagogiques : Les objectifs pédagogiques du module sont définis collectivement lors des réunions du GRR.
- Développement du support : Le développement du support est confié à une petite équipe issue du GRR, en fonction des disponibilités et des compétences.
- Test du support : Le support proposé est testé par les référents R au cours d’une séance collégiale, qui vérifie l’adéquation de la durée du module, sa facilité de compréhension, et le respect des objectifs et principes pédagogiques.
- Formalisation des améliorations : Les retours et les demandes d’amélioration sont formalisés sous forme de tickets, et le module est ajusté en conséquence.
- Déploiement : Une fois les modifications effectuées et validées, le nouveau module est prêt à être déployé.
Arborescence du wiki du parcours-r