Introduction

Le guide ci-dessous décrit la procédure conseillée pour encadrer la contribution des membres non-permanent du LIS (stagiaires, étudiants, ingénieurs en CDD…) à des projets de développement logiciel menés au LIS. Ce guide se place du côté de l’encadrant, la procédure à suivre du côté du contributeur encadré étant décrite sur cette page.

Cette procédure n’est cependant pas réservée à l’encadrement des membres non-permanents du LIS et ce mode de fonctionnement peut être retenu pour la contribution de n’importe lequel des membres du LIS.

Cette procédure est notamment pensée pour faciliter l’encadrement de membres non permanents par des membres permanents (enseignants/chercheurs, ingénieurs) et permettre un bon contrôle de la qualité des développements intégrés dans les projets.

IMPORTANT : si les développements réalisés par un stagiaire ont vocation à être diffusés ou valorisés, il est nécessaire de faire signer au stagiaire en fin de stage une annexe à la convention de stage de cession des droits de propriété intellectuelle. Un modèle pour la rédaction de cette annexe est disponible ici.

La procédure s’appuie sur l’utilisation du serveur GitLab du LIS et des dépôts Git qu’il fournit. L’ouverture d’un compte informatique au LIS pour le membre non-permanent est donc un préalable à la procédure.

Si l’utilisation de Git et de GitLab ne vous est pas familière, il vous est très fortement conseillé de consulter les pages sur Git et sur GitLab.

Initialisation du projet

• Si le projet GitLab principal sur lequel doit travailler le contributeur est privé, vous devez lui donner accès au projet afin qu’il puisse créer le projet fourche GitLab dans lequel il travaillera.
• Pensez à configurer les options de notification du projet fourche du contributeur à votre convenance. Vous voudrez probablement être notifié des événements dans le projet fourche pour suivre le travail du contributeur que vous encadrez.

Développement et partage du code avec l’encadrant

• Le contributeur réalise ses développements dans son projet GitLab fourche. Vous pouvez donc exploiter les outils à votre disposition dans GitLab pour encadrer son travail. Vous pouvez en particulier utiliser :
  • le dépôt Git du projet fourche pour récupérer le code du contributeur, et éventuellement contribuer au développement du code,
  • le système de tickets, utilisable notamment pour signaler des bogues ou des améliorations et gérer et planifier des tâches (voir quelques utilisations possibles),
  • le wiki du projet qui peut trouver de nombreuses utilisations,
  • la possibilité d’ajouter des commentaires sur les commits, y compris en commentant des portions précises du code, par exemple pour signaler des problèmes ou des améliorations au contributeur.
• Lorsqu’une fonctionnalité est prête à être intégrée dans le dépôt principal, le contributeur fait une demande de fusion (merge request). Là aussi, profitez des outils disponibles dans GitLab pour réaliser votre revue de code et utilisez le système de commentaires intégré aux demandes de fusion pour communiquer avec le contributeur si nécessaire, par exemple pour demander des précisions sur des portions de code, ou encore demander des corrections ou des améliorations avant fusion.

Fin du projet

Lors du départ du LIS du contributeur, pensez à archiver ou à supprimer son projet fourche dans GitLab (voir la section “Settings” du projet).

Choisissez l’archivage du projet si vous pensez que certains éléments du projet pourrait être utiles dans le futur, par exemple certains commentaires faits sur des commits, certains tickets, le contenu du wiki, des branches dans le dépôt Git qui n’ont pas été fusionnées dans le dépôt principal…

Si au contraire vous pensez que tous les éléments nécessaires aux développements futurs ont été intégrés dans le projet principal et qu’aucun élément du projet fourche ne sera utile dans le futur, vous pouvez supprimer le projet fourche.