Travailler à plusieurs ? Communiquer ?

Quand on a un problème de resel, on le résoud. On regarde d'abord sur internet, le wiki, et si y'a pas l'info, on demande sur Telegram. Comme tu peux le remarquer, Telegram est adapté pour des discussions en temps réel, de l'aide en direct.

Quand on ne communique pas en direct, les fils de conversations officiels du ResEl deviennent une perte de temps. Pleins d'informations sur pleins de projets passent, et il est impossible de suivre un conversation donnée la veille. Pour les petits malins, il ne faut pas créer de channels Telegram privés. Ces channels cloisonnent l'information. Pour toute personne en dehors du chan, tout les trucs importants sont perdus à jamais.

C'est pour ça qu'on a deux structures qui permettent de garder les informations facilement accessibles et ouverte à tous :

• un wiki qui donne des explications sur comment fonctionnent nos systèmes, quel est l'organisation, comment faire pour réaliser une tâche.
• Un système d'issues (https://git.resel.fr/resel/general/issues) La règle est que dès que tu t'occupes d'un problème, et que tu n'as pas le temps de terminer de le régler, tu écris une issue !

Une issu-quoi ?

En théorie, une issue c'est une action élémentaire (mais non triviale) à réaliser par une personne. 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.

Les issues sont rassemblées dans un onglet du git.resel.fr :

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".

Quand on réalise un projet, comme celui de monitoring, on s'attaque à un problème complexe. Vous savez ce qu'on fait à un problème complexe ? on le divise en sous-problème jusqu'à arriver à des tâches réalisables. 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). 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. Je répète : Issue ouverte = problème à résoudre, et Issue fermée = problème résolu.

Le soucis, c'est qu'on reçoit beaucoup d'issues, du coup on a besoin de s'organiser. 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.

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).

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. 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.

Ça, ça s'appelle du travail de traçabilité et de documentation.