Guides/Comment-fonctionnes-les-issues.md
... ...
@@ -14,22 +14,30 @@ La règle est que dès que tu t'occupes d'un problème, et que tu n'as pas le te
14 14
En théorie, une issue c'est une action élémentaire (mais non triviale) à réaliser par une personne.
15 15
Elle contient un titre, une description, et des commentaires. Il y a aussi une échéance, une personne assignée à l'issue, une milestone et des labels.
16 16
17
-Les issues sont rassemblées dans un onglet du git.resel.fr :
18
-
19
-Le système d'issue sert à lister des actions à réaliser, par exemple pour résoudre des problèmes comme "je connais pas la liste des scripts exécutés sur Echelon", "Cette machine a besoin qu'on nettoie sa mémoire et vide sa corbeille".
20
-
21
-Quand on réalise un projet, comme celui de monitoring, on s'attaque à un problème _complexe_.
22
-Vous savez ce qu'on fait à un problème complexe ? on le divise en sous-problème jusqu'à arriver à des tâches *réalisables*.
23 17
Pour que tout le monde connaisse ces tâches à réaliser, il faut que vous écriviez des issues, une issue par tâche à réaliser (environ).
24 18
Cette issue doit décrire le problème à résoudre et la tâche à effectuer. Elle est considéré dans un état _ouvert_ jusqu'à qu'elle soit résolue. On décide alors de la _fermer_.
25
-Je répète : Issue ouverte = problème à résoudre, et Issue fermée = problème résolu.
19
+Je répète :
20
+- Issue ouverte = problème à résoudre
21
+- Issue fermée = problème résolu.
22
+
23
+## Organisation des issues
24
+Les issues sont rassemblées dans un [onglet du git.resel.fr](https://git.resel.fr/resel/general/issues)
25
+
26
+Le système d'issue sert à lister des actions à réaliser, par exemple pour résoudre des problèmes comme "je connais pas la liste des scripts exécutés sur Echelon", "Cette machine a besoin qu'on nettoie sa mémoire et vide sa corbeille".
26 27
27 28
Le soucis, c'est qu'on reçoit beaucoup d'issues, du coup on a besoin de s'organiser.
28 29
Il faut tout d'abord savoir que les issues sont reliées à un _repo git_. Exemple, le repo dhcp-brest contient les issues reliées à ce projet (link : https://git.resel.fr/confs/dhcp-brest/issues). Au resel, quand on ne sait pas où mettre un issue, on la met dans le repo _Général_ (https://git.resel.fr/resel/general/issues). C'est le dossier qui contient la plupart des issues. Celles hors de ce repo concerne des problèmes spécialisés, exemple : le DHCP.
29 30
30 31
Le but est, en tant qu'admin, que tu sois au courant des issues dans le repo Général. Et que, quand tu as du temps, tu t'occupes de régler les problèmes dans ces issues, à la mesure de ce que tu es capable de faire. (pour ça, soit tu choisis un issue et tu demandes de l'aide, soit tu demandes à ce qu'on t'attribue une issue, sur le chan #resel).
31 32
32
-Quand on réalise un projet de l'ampleur du projet monitoring, on a besoin d'avoir une organisation, un suivi clair des étapes. La liste des issues dans un repo ne permet pas de s'organiser : il n'y a pas de coordination entre les issues, ce sont juste des problèmes isolés.
33
-Les cerveaux de gitlab, github, et toutes les grandes sociétées spécialisées dans la gestion de projet, le partage du travail, la coordination du codage ont eu une idée. On rédige ce qu'on appelle des milestones. Une milestone représente un projet, et contient une liste d'issue, qu'il faudra résoudre petit à petit pour compléter le projet. Dans la milestone, on donne une description du projet. La théorie dit que n'importe qui qui débarque du futur peut arriver sur un projet, lire la milestone, les issues, et savoir quoi faire pour avancer sur le projet.
33
+## Gérer des projets : Des milestones
34
+
35
+Quand on réalise un projet, comme celui de monitoring, on s'attaque à un problème _complexe_.
36
+Vous savez ce qu'on fait à un problème complexe ? on le divise en sous-problème jusqu'à arriver à des tâches *réalisables*.
37
+
38
+On a besoin aussi d'avoir une organisation, un suivi clair des étapes. La liste des issues dans un repo ne permet pas de s'organiser : il n'y a pas de coordination entre les issues, ce sont juste des problèmes isolés.
39
+Les cerveaux de gitlab, github, et toutes les grandes sociétées spécialisées dans la gestion de projet, le partage du travail, la coordination du codage ont eu une idée.
40
+
41
+On rédige ce qu'on appelle des milestones. Une milestone représente un projet, et contient une liste d'issue, qu'il faudra résoudre petit à petit pour compléter le projet. Dans la milestone, on donne une description du projet. La théorie dit que n'importe qui qui débarque du futur peut arriver sur un projet, lire la milestone, les issues, et savoir quoi faire pour avancer sur le projet.
34 42
35 43
Ça, ça s'appelle du travail de traçabilité et de documentation.