feat: update gitlab templates and add some : Release, Refacto

.gitlab/issue_templates/Bug.md

@@ -1,4 +1,4 @@
-Préconisations générales: 
+Préconisations générales:
 1. Pensez à bien mettre un **titre** d'issue explicite par rapport au bug
 2. Pensez à essayer au maximum d'aider le support (best effort) avec des informations les plus claires et précises
 3. Mettre le bon label
@@ -12,19 +12,19 @@ Préconisations générales:
 ### Contexte
 (ce qui permet de rejouer le bug)
 
-- Version de cars utilisée (cars --version): 
+- Version utilisée (cars --version):
 
-- Contexte d'utilisation (module load, cars-hal, source, ...): 
+- Contexte d'utilisation: module, cars-hal, source
 
-- Commande utilisée
+- Commande utilisée:
 
-#### Configuration et données utilisées 
+#### Configuration et données utilisées
 
 *Copier le input.json(prepare) ou le content.json (compute_dsm) (si applicable)*
 
 *Pensez à vérifier l'accès par les autres à la donnée en entrée ou copiez dans*
 
-#### Environnement 
+#### Environnement
 *Copier l'environnement python*
 
 ```
@@ -33,12 +33,10 @@ pip freeze
 *Lister l'environnement modules*
 ```
 module list
-``` 
+```
 
 
 ### Pistes potentielles pouvant expliquer l'origine du bug
 
 
 ### Pistes potentielles pouvant corriger le bug
-
-

.gitlab/issue_templates/Proposal.md

@@ -9,7 +9,7 @@
 
 ### Proposition
 
-**Résumé**  
+**Résumé**
 
 *Pensez à ajouter les labels associés à la proposition*
 

.gitlab/issue_templates/Refacto.md

@@ -0,0 +1,36 @@
+Préconisations générales:
+1. Pensez à bien mettre un **titre** d'issue explicite par rapport au domaine de refactoring/reconception.
+2. Pensez à essayer au maximum d'aider un développeur qui devra reprendre ce travail ou relire avec des informations synthétiques les plus claires et précises
+
+Il est important d'essayer de se mettre à la place de quelqu'un d'autre qui relira, ou dans la perspective d'une présentation à quelqu'un d'autre pour transférer le travail.
+
+/label ~"Kind - Refacto"
+
+### Contexte
+Cette section donne le contexte général du refactoring prévu.
+
+### Documentation API et fonctionnel
+
+Cette partie décrit le fonctionnement du module/domaine visé par l'issue.
+
+1. décrire bien ce que fait le bloc logiciel à haut niveau avec API utilisateurs et internes (nom fonctions, paramètres, noms de structures de données (classe ou autre) explicites )
+2. décrire fonctionnellement les blocs avec le principe de base à haut niveau.
+
+Des schémas UML sont toujours bien pour des classes.
+
+Les objectifs:
+- qu'un utilisateur sache exactement ce que fait le module par l'API
+- qu'un autre développeur puisse comprendre/relire/reprendre le travail rapidement
+
+### Plan de validation / tests
+
+Cette section décrit la manière de tester le domaine fonctionnel du refactoring prévu.
+
+En cohérence avec la documentation fonctionnel, cette section doit décrire **précisément** la façon de tester le module logiciel visé.
+
+Il est important de considérer:
+- les tests unitaires pour les fonctions de base
+- les tests fonctionnels du  module : que doit on voir fonctionner pour que le module soit valide ?
+- considérer le temps de calcul et séparer si des tests sont trop lourds
+
+Utiliser les @pytest.mark pour organiser les tests suivant la découpe d'organisations des tests choisie.

.gitlab/issue_templates/Release.md

@@ -0,0 +1,15 @@
+Release <numero_version>
+
+/label ~"Kind - Release"
+
+Liste de points à vérifier/faire pour la release en cours:
+
+- [ ] Vérifier issues milestone (mettre lien milestone avec %nom_milestone)
+- [ ] Finaliser Changelog de la version en cours: Vérifier en comparant avec les issues/MR du milestone de la version.
+- [ ] Mise du tag sur la version finale après dernieres MR.
+- [ ] Vérification Publication code sur github, read the docs, pypi
+- [ ] Dernière Vérification si installation, tests, ...  (relance CI ou manuellement si pas automatique dans CI)
+- [ ] Tests et Upgrade cars-hal
+- [ ] Ajout dans module load si necessaire suivant projet
+- [ ] Génération image docker et Publication du docker (pas automatique pour l'instant)
+- [ ] Communication sur la release (si nécessaire mailing list ou autre)

.gitlab/merge_request_templates/MR.md

@@ -1,34 +1,53 @@
+**A choisir dans le template les éléments à garder suivant le développement à faire.**
+
+Si la Merge Request est en cours de développement, merci d'ajouter le mot clé `WIP` ou `Draft` afin d'éviter la fusion de cette dernière.
+
 #### Résumé de la proposition
 
-#### Détails techniques de l'implémentation (si besoin)
+1. Que fait la MR ? (bien etre explicite sur le titre)
+2. Liste des taches de la MR qui répondent à l'issue (partiellement ou globalement suivant si Closes ou Relates)
+3. Etat du Reste à faire à reprendre pour finir l'issue
+4. Lien vers l'issue source (Closes si la MR ferme l'issue, Relates si en fait une partie)
+
+A choisir:
+Closes #num_issue
+Relates #num_issue
+
+#### Détails techniques de l'implémentation
+
+Cette section décrit les solutions techniques que la MR met en oeuvre et qui répondent à la description fonctionnelle de l'issue associée.
 
 #### Stratégie de validation
 
-- [ ] Tests Unitaires ? (obligatoire pour du `feat` et `fix`)
+En lien avec le plan de validation de l'issue, il faut décrire la stratégie de validation dont s'occupe la MR.
+Au moins :
+- [ ] Tests Unitaires (obligatoire)
+- [ ] Tests Fonctionnels (intégration / interfaces avec d'autres outils)
+- [ ] Tests Performances
+
+Si besoin suivant l'issue/MR:
 - [ ] Tests Visuels ? (doc)
-- [ ] Tests Fonctionnels ? (intégration / interfaces avec d'autres outils)
 - [ ] Tests Comparatifs ? (`feat` métier avec outil de référence)
-  - dans ce cas citer l'outil et son paramétrage 
-
-#### MR non prête à merger
+  - dans ce cas citer les outils et leur paramétrage
 
-Si la Merge Request est en cours de développement, merci d'ajouter le mot clé `WIP` afin d'éviter la fusion de cette dernière.
 
-#### MR prête à merger 
+#### Validation de la MR
 
 Si la Merge Request est prête, merci de valider les étapes suivantes:
-- [ ] mise à jour de la documentation Sphinx et vérification du résultat. 
+- [ ] mise à jour de la documentation Sphinx et vérification du résultat.
+- [ ] tous les tests passent et la MR est couverte par la stratégie de validation
 - [ ]  mise à jour du changelog Changelog.md
   - uniquement si la MR rempli l'un des objectifs suivants:
     - correction d'un bug
     - ajout d'une fonctionnalité métier
     - ajout d'une fonctionnalité à destination du grand public (communication)
   - suivre les recommandations de https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md
     - inscrire la modification sous le titre `Unreleased`
+- [ ] S'assurer qu'il y a toutes les infos dans la MR pour qu'un autre développeur puisse relire facilement, ce qu'on s'attendrait à avoir soi même pour relire la MR (cf résumé ci dessus)
 
-#### Integration Continue
+#### Rappel Intégration Continue
 
-Pour relancer l'intégration continue merci de laisser le commentaire suivant :  
+Pour relancer l'intégration continue merci de laisser le commentaire suivant :
 `Jenkins! Faster!! And you'd better make it work !`