Dès ses débuts, le projet modulo a été pensé pour accepter des contributions venant de l'ensemble des enseignant·e·s d'informatique à charge d'enseigner cette nouvelle matière au gymnase.
Le document ci-présent explique les étapes permettant une contribution saine et fructueuse.
Les contributions sont optionnelles, et engagent le bon vouloir des personnes qui s'y adonnent. Il est donc d'autant plus important de comprendre que pour une raison évidente de cohérence et de continuité du projet, l'équipe modulo possède un droit de regard sur ce qui est accepté et, en dernier lieu, publié. Les contributions doivent donc être faites avec une approche détaillée dans le code de conduite.
Le document ci-présent explique la marche à suivre pour effectuer des contributions. En aucun cas il ne prétend qu'une contribution, même si elle remplit les critères détaillés ci-dessous, soit de facto acceptée.
Peut contribuer au projet modulo toute personne ayant pris connaissance des documents importants de ce dépôt que sont le README, le code de conduite, ainsi que le document ci-présent, et opérant selon la marche à suivre décrite ci-dessous.
Une première étape consiste à lire les contenus actuellement en ligne. Sans même entrer dans les détails de l'utilisation de GitHub comme plateforme de contribution, vous pouvez nous signaler tout défaut ou problème rencontré à [email protected].
Dans un second temps, il peut-être utile de participer au enquêtes et sondages décrits ici au point 1, qui nous permettent d'avoir un feedback sur l'appréciation des contenus créés.
Par la suite, et quand vous vous serez familiarisé avec les différents aspects du projet mentionnés dans la documentation présentée ci-dessus, sentez-vous libres de nous adresser n'importe quel retour, positif ou négatif, via les canaux de communication suivants, ou n'importe quel autre que vous jugerez opportun. Il est important de comprendre qu'il est préférable de vous adresser aux personnes responsables de la thématique sur laquelle porte votre retour.
Le lien suivant vous donne accès à un channel Discord : https://discord.com/invite/b8qu79t6HQ. Nous l'utilisons comme outil de communication rapide et publique. Il faut garder à l'esprit que le channel est accessible à n'importe qui (nous n'opérons pas de modération des accès).
Les adresses suivantes sont celles des responsables de thématiques.
L'adresse générale pour nous atteindre est [email protected]. Elle est relevée par l'équipe LEARN chargée de la gestion du projet modulo.
Si vous possédez déjà du matériel d'enseignement que vous seriez d'accord de partager en l'état, vous êtes les bienvenus à nous transmettre, via le lien pour notre dropbox Kdrive ci-dessous, tout ce que vous jugeriez approprié.
À ce stade, le partage de vos contenus n'est pas censé respecter de charte, ou de règlement particulier au niveau du contenu autant que de la forme. Le but ici est simplement de nous donner accès à du matériel que vous jugez pertinent, en nous laissant le soin de voir si nous pouvez le mettre en forme pour l'intégrer à nos contenus. Nous parlons ici d'activités, de séries d'exercices, d'éléments de théorie, de planifications de cours, d'indications pédagogiques sur des notions particulières, de glossaires, enfin de tout contenu que vous utilisez et jugez pertinent dans cadre du plan d'études de la branche en question.
Il est important de comprendre qu'en déposant des fichiers sur notre dropbox ci-dessous, vous nous donnez tacitement la possibilité de modifier et de transformer vos ressources pour les adapter au projet ci-contre. Bien sûr, une mention sera toujours faite de l'origine du document, et vous serez consulté avant la moindre publication ou le moindre partage plus loin.
Dropbox Kdrive : https://drive.infomaniak.com/app/collaborate/392255/1cc7e2a1-2d3f-4e70-ab7e-c297d9bdb4eb
Une charte, ainsi qu'une convention fixent les limites dans lesquelles le projet est susceptible d'être patagé. Il va de soi que le contrôle total étant impossible, nous demandons ici du fair-play de votre part.
Tout enseignant·e souhaitant contribuer activement au projet est cordialement invité·e à le faire. Celles et ceux qui sont familiers avec GitHub peuvent immédiatement aller au chapitre installation. Pour les autres, la lecture de ce qui suit est primordiale.
Les chapitres qui suivent ont pour vocation d'expliquer comment utiliser les différents outils offerts par GitHub, et non de les décrire. Pour cela, il convient de se référer au Wiki.
Les "Good First Issue" sont, dans la nomenclature traditionnelle des dépôts GitHub, des "problèmes faciles à résoudre" auxquels peuvent s'attaquer des utilisateurs·trices novices.
Un fork est une copie non-linkée des fichiers sources du dépôt. Il permet à quiconque de dupliquer toutes les sources et les aménager à sa guise sans qu'un suivi soit efectué depuis le dépôt source. Pour la définition détaillée, voir ici.
Une des utilisations possibles de ces ressources via GitHub consiste simplement à les "forker", c'est à dire les dupliquer mais sans conserver la "parentalité" du dépôt source (a contrario du processus appelé "clône", qui conserve les attaches entre les sources et le clone, cf : ci-dessous).
N'oubliez simplement pas de faire mention de la licence sous laquelle ces ressources sont publiées.
Un clône est une copie "linkée" des ressources, qui conserve les liens de parentalité et donc d'interation entre source et clône. Un clône comprend les différentes branches du dépôt source. Pour la définition détaillée, voir ici.
Une branche est un duplicata des fichiers sources à un moment donné, qui permet de travailler sur l'un ou l'autre aspect des sources sans affecter la version "principale" (appelée ici "master", aussi appelée parfois "main"). Pour la définition détaillée, voir ici.
Dans ce dépôt, les branches spéciales sont :
- master : c'est la branche par défaut, celle sur laquelle sont stockées les sources générant la version actuelle des ressources.
- dev : c'est la branche en développement, celle sur laquelle les nouvelles versions sont stockées, servant à générant la version en développement des ressources
- old-master : c'est la branche d'archive, celle sur laquelle est stockée la version antérieure des ressources.
Un commit est l'équivalent d'une "sauvegarde" sur une branche d'un dépôt GitHub. L'utilisateur qui modifie un fichier doit ensuite soumettre (commit) sa modification pour que les autres utilisateurs puissent la voir.
Dans l'exemple ci-dessous, les modifications que je fais au document ci-contre doivent être soumises (commit changes) pour être rendues effectives.
Dans la pratique, il convient d'utiliser l'option "create a new branch for this commit and start a pull request".
Si on décortique les étapes d'une telle fonction, on a :
- Création d'une branche
- Ajout d'un commit sur cette nouvelle branche
- Demande au master de "pull" (c'est à dire tirer à vers soi) cette nouvelle branche pour que la modification soit effective
Concrètement, ces étapes permettent aux modérateurs du dépôt de traiter le nouveau commit comme si c'était une branche qui souhaitait merger les nouvelles modifications apportées dans le master.
Un pull request est une requête dont le destinateur est la branche qui souhaite amener une modification, et le destinataire est la branche sur laquelle on souhaite que cette modification soit apportée. En d'autres termes, c'est une demande que l'utilisateur d'une branche adresse à l'administrateur d'une autre branche pour que celle-ci "tire vers soi", un certain nombre de modifications contenues dans la branche.
Lorsqu'il est proposé le pull request est l'objet d'un processus de validation décrit ci-dessous.
GitHub permet d'ajouter des routines de protection des branches, qui consistent en droits d'écriture pour des utilisateurs particuliers, ou des groupes.
Dans ce dépôt, les branches protégées sont les branches spéciales. Sur ces branches, seul le comité de rédaction peut effectuer des commits ne nécessitant pas d'être validés par des pairs.
Pour les autres utilisateurs, toute modification des sources passe par une relecture et une acceptation. Les membres ayant le droit d'accepter des modifications pour leurs dossiers respectifs sont déclarés dans le document CODEOWNERS
Pour chaque thématique présente dans les ressources, il existe un certain nombre de responsables de thématiques qui seront les interlocuteurs privilégiés pour des modifications apportées aux sources en question. Ce sont eux qui observeront les modifications apportées et les valideront si elles sont acceptées. Dans le jargon, ce sont les reviewers des pull request qui concernent leur thématique.
Une charte rédactionnelle, disponible ici, décrit les contraintes d'écriture.