Différences

Ci-dessous, les différences entre deux révisions de la page.

--- fr:collabo_py_nel [2018/06/10 10:49] – créée YannK
+++ fr:collabo_py_nel [2021/12/03 18:19] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 5: / Ligne 5: @@
 Ce module permet de lire et écrire avec des modules Python 3 les différents fichiers aux formats spécifiques de la library NeL (NEvrax Library) tels que .shape, .skel, .anim, .ps…
-Il permettra à des applications tierces d’accéder aux données OpenNeL pour les créer, les manipuler, les éditeur. Son premier usage sera un ensemble de plugins Blender : [[fr:collabo_bpy_nel_workbench|bpyNeL Workbench]]
+Il permettra à des applications tierces d’accéder aux données OpenNeL pour les créer, les manipuler, les éditer. Son premier usage sera un ensemble de plugins Blender : [[fr:collabo_bpy_nel_workbench|bpyNeL Workbench]]
@@ Ligne 12: / Ligne 12: @@
 ==== Mise en place d'un dépôt personnel (fork) ====
-Pour commencer, il vous faudra forker le dépôt principal. Ainsi, vous aurez votre propre dépôt, sur lequel vous pourrez effectuer vos modification sans interférer avec le dépôt principal.
+Pour commencer, il vous faudra forker le dépôt principal. Ainsi, vous aurez votre propre dépôt, sur lequel vous pourrez effectuer vos modifications sans interférer avec le dépôt principal.
-Pour cela, il vous suffit de clique sur le bouton suivant sur la page d’accueil du projet.
+Pour cela, il vous suffit de cliquer sur le bouton suivant sur la page d’accueil du projet.
 {{:fr:fork.png}}
-Vous serrez alors redirigé vers votre copie du dépôt.
+Vous serez alors redirigée vers votre copie du dépôt.
 ==== Travailler directement sur le dépôt principal ====
-Si vous êtes un développeur "officiel" (avec une autorisation d'accès dans le groupe Khaganat ) chez nous, vous aurez accès au dépôt principal sur notre GitLab : [[gitlab>py_nel_project/py_nel|pyNeL]].
+Si vous êtes une développeuse "officielle" (avec une autorisation d'accès dans le groupe Khaganat) chez nous, vous aurez accès au dépôt principal sur notre GitLab : [[gitlab>py_nel_project/py_nel|pyNeL]].
 Vous n'aurez pas à créer un dépôt personnel (sauf si vous en avez envie) pour pouvoir contribuer, il vous suffira de travailler sur des branches en interne.
@@ Ligne 33: / Ligne 33: @@
 Les branches principales sont :
-  * Branche **Master** : Branche **stable**, où seul les hotfix et les nouvelles release sont autorisés à être mergés. Cette branche garantie une expérience sans (trop de) bugs, dans la mesure du possible.
+  * Branche **Master** : Branche **stable**, où seuls les hotfix et les nouvelles releases sont autorisées à être mergées. Cette branche garantit une expérience sans (trop de) bugs, dans la mesure du possible.
-  * Branche **Develop** : Branche de développement, dans laquelle les features terminés sont mergés, en vu des futures releases.
+  * Branche **Develop** : Branche de développement, dans laquelle les features terminées sont mergées, en vue des futures releases.
-A cela s'ajoute des branches temporaires, ouvertes et fermés suivants les besoins:
+À cela s'ajoutent des branches temporaires, ouvertes et fermées suivant les besoins:
-  * Branche **Feature** : C'est **une nouvelle addition** au code, développée dans une branche séparée afin de réduire les risque d'introduction de bugs dans develop. Elle sera à merge sur la branche "develop".
+  * Branche **Feature** : C'est **une nouvelle addition** au code, développée dans une branche séparée afin de réduire les risques d'introduction de bugs dans ''develop''. Elle sera à merger sur la branche ''develop''.
-  * Branche **Release** : Ce type de branche est **spécifique au dépôt principal**, et est crée quand toutes les feature prévu dans une nouvelle release ont été merge dans develop. Une fois cette branche créée, seuls les bugfix y sont autorisés, jusqu'à ce qu'elle soit mergée dans Master, une fois considéré comme suffisamment stable pour la "production".
+  * Branche **Release** : Ce type de branche est **spécifique au dépôt principal**, et est créée quand toutes les features prévues dans une nouvelle release ont été mergées dans ''develop''. Une fois cette branche créée, seuls les bugfix y sont autorisés, jusqu'à ce qu'elle soit mergée dans Master, une fois considéré comme suffisamment stable pour la "production".
-  * Branche **Hotfix** : C'est une branche ayant pour objectif de **rapidement corriger un bug critique affectant Master**. De ce fait, elle sera mergée vers la branche Master, ainsi que "develop".
+  * Branche **Hotfix** : C'est une branche ayant pour objectif de **rapidement corriger un bug critique affectant Master**. De ce fait, elle sera mergée vers la branche Master, ainsi que ''develop''.
-Les branches, que ce soit sur votre fork ou sur les dépôts officiels, doivent être nommé de la façon suivante:
+Les branches, que ce soit sur votre fork ou sur les dépôts officiels, doivent être nommées de la façon suivante:
   * Branche **Feature** : Doit être nommée "feature/[numéro(s) de(s) (l')issue][nom de la feature sans espaces ni ponctuation]"
@@ Ligne 55: / Ligne 55: @@
 ==== Publication d'une feature ====
-Une fois que vous considérez la feature que vous avez développé terminé, vous pouvez créer une Merge Request, à destination de **Develop**. Cette requête doit respecter ces impératifs :
+Une fois que vous considérez la feature que vous avez développé terminée, vous pouvez créer une Merge Request, à destination de **Develop**. Cette requête doit respecter ces impératifs :
-  * Le CI Gitlab doit pourvoir la compiler avec succès.
+  * Le CI Gitlab doit pouvoir la compiler avec succès.
-  * La feature et son code doivent être documentée.
+  * La feature et son code doivent être documentées.
-  * La Merge Request doit clairement expliquer la feature (son utilisation, les test à effectuer, etc.)
+  * La Merge Request doit clairement expliquer la feature (son utilisation, les tests à effectuer, etc).
 ==== Publication d'une release ====
-Une fois un certain nombre de features sont mergés avec Develop, nous créons une nouvelle branche release. A partir de ce moment, seul les bugfix sont acceptés (code freeze).
+Une fois un certain nombre de features mergées avec Develop, nous créons une nouvelle branche release. À partir de ce moment, seuls les bugfix sont acceptés (code freeze).
-Une fois le nouveau code testé, et les bugs corrigés, la release est tagué, et publié dans master.
+Une fois le nouveau code testé, et les bugs corrigés, la release est taguée et publiée dans master.
 ==== Créer un HotFix ====
-Il arrive que des bugs critiques passe à travers les maillons du filet de la QA, c'est pourquoi il est parfois nécessaire de faire des "hotfix" (correction à chaud).
+Il arrive que des bugs critiques passent à travers les maillons du filet de la QA, c'est pourquoi il est parfois nécessaire de faire des "hotfix" (correction à chaud).
 Pour cela, il faut faire une branche "hotfix" depuis master, y corriger le bug, puis le publier dans master.
@@ Ligne 83: / Ligne 83: @@
 ===== Gestion des Issues =====
-De préférence à la [[taf>fr:start|la base TAF]], créez les demandes d'ajout de features sur le système Gitlab de ce dépôt. Bien évidement, les //Bugs// liés à la programmation sont à signaler ici également.
+De préférence à [[taf>fr:start|la base TAF]], créez les demandes d'ajout de features sur le système Gitlab de ce dépôt. Bien évidement, les //Bugs// liés à la programmation sont à signaler ici également.
 De même, avant de commencer une tâche, créez une Issue que vous vous attribuez, comme ça vous pouvez numéroter la branche correctement et on sait que quelqu'un a commencé à travailler sur ce sujet.
-Les travaux à faire, modifications de fichier, créations, doivent être indiqués en se servant du système d'//Issues// de ce dépôt : [[gitlab>py_nel_project/py_nel/issues|Issue sur pyNeL]]
+Les travaux à faire, modifications de fichier, créations, doivent être indiquées en se servant du système d'//Issues// de ce dépôt : [[gitlab>py_nel_project/py_nel/issues|Issue sur pyNeL]]
 Il suffit de cliquer sur : {{ :fr:new_issue2.jpg?nolink |}}
@@ Ligne 104: / Ligne 104: @@
 Dans le doute, n'indiquez rien dans ces quatre champs. De toute façon, tout est éditable a posteriori donc ce n'est pas grave si vous faites des erreurs ou n'êtes pas assez précis.
 ===== Gestion des Milestones =====
@@ Ligne 111: / Ligne 112: @@
 Nous n'utilisons pas de //Tags// sur ce dépôt Git pour le moment.
 ===== Gestion des Labels =====