update team organisation documents

doc/adr/dev-process-PR.md

@@ -2,16 +2,16 @@
 
 ## 2023/04/25 - Process de dev
 
-1. Dans stories priorisé on est sensé avoir les story qui sont prêtes à être développées (description claire, intervenants et partenaires identifiés sur le ticket)
+1. Dans stories priorisé, on est censé avoir les story qui sont prêtes à être développées (description claire, intervenants et partenaires identifiés sur le ticket)
 2. Les story à "faire dans l'itération" sont les prochaines à être développées
 3. Les dev se mettent d'accord entre eux sur qui prend quoi
-4. (une fois sur github) Les PR doivent référencer les issues qu'ils implémentent (donc on est sensé créer une issue pour chaque PR commencée)
-5. Les dev doivent indiquer s'ils ont besoin d'une review en déplaçant l'issue dans le kanban (à "to review")
-6. Les reviewers font leur commentaire et indique si c'est apprové ou pas.
+4. Les PR doivent référencer les issues qu'elles implémentent (donc on est censé créer une issue pour chaque PR commencée)
+5. Les dev doivent indiquer s'ils ont besoin d'une review en déplaçant l'issue dans le kanban (à "to review" + message dans le Discord sur #dev)
+6. Les reviewers font leur commentaire et indiquent si c'est approuvé ou pas.
 7. S'il y a besoin de changement, l'issue retourne au status in progress
-8. Si c'est ok, elle est apprové (et/ou on met tag "ready to merge")
-9. Le dev qui a fait la feature est celui qui merge sur la branche "dev"
-10. Avant de pousser une staging, un dev doit prévenir sur discord en notifiant @dev (n'importe quel dev peut le faire)
-11. On prévient le métier qu'il doit faire la recette sur staging en créant un thread sur discord
-12. Quand le métier dit GO : on pousse sur main ce qui lance un déploiement en prod
-13. S'il y a quelque chose qui bloque les merges sur dev, il faut prévenir sur discord. Et quand c'est résolu, il faut prévenir sur discord qu'on peut de nouveau merger normalement
+8. Si c'est ok, elle est approuvé (et/ou on met tag "ready to merge")
+9. Le dev qui a fait la feature est celui qui merge sur la branche "main"
+10. Avant de pousser une staging, un dev doit prévenir sur Discord en notifiant @dev (n'importe quel dev peut le faire), sur le channel #dev
+11. On prévient le métier qu'il doit faire la recette sur staging en créant un thread sur Discord (dans #staging-notifications, en partant de message de mise en staging)
+12. Quand le métier dit GO : on pousse lance de déploiement en prod
+13. S'il y a quelque chose qui bloque les merges sur 'main', il faut prévenir sur Discord (sur #general ou #dev). Et quand c'est résolu, il faut prévenir sur discord qu'on peut de nouveau merger normalement

doc/adr/dev-team-organisation.md

@@ -14,37 +14,37 @@
   - simulated et tests gateway ?
   - quand est-ce qu'on peut utiliser le state interne de redux dans des Epics ?
   - comment on organise les routes du backend pour s'y retrouver plus facilement ?
-- 2023-02-16 - On peut sanctuariser un moment pour avoir ces discussions
+- 2023-06-19 - Un moment a été sanctuarisé le mardi après midi, à 14h
 - 2023-02-16 - L'ensemble de ces discussions a pour objectif que l'équipe converge vers des bonnes pratiques. Et l'équipe devra les respecter.
 
 ### Le pair programming
 
 - 2023-02-16 - On essaye de bosser autant que possible en pair programming. Il y a une certaine flexibilité mais c'est une méthode de travail qui permet d'avoir un regard croisé sur les features, et est plus efficace que les reviews à postériori.
-- 2023-02-16 - Pas une règle absolu, mais il faut conserver cette objectif de pair autant que possible. Si pas possible, une review est necessaire, et éventuellement une discussion _a posteriori_.
+- 2023-02-16 - Pas une règle absolue, mais il faut conserver cette objectif de pair autant que possible. Si pas possible, une review est nécessaire, et éventuellement une discussion _a posteriori_.
 
 ## Le role de développeur
 
-- 2023-02-16 - Développe les fonctionnalités (ou résolution de bug) selon leur priorisation par le métier lors des revues de trello.
-- 2023-02-16 - Est responsable du bon maintient en condition opérationnel des applications
-- 2023-02-16 - Est force de propositions sur les methodes pour mettre en place ces fonctionnalitées. Les décisions sont prises en pair, ou seul si le travail est fait seul.
-- 2023-02-16 - En cas de doute, le developpeur (ou l'équipe de pair) doit contacter les membres de l'équipe qui peuvent le débloquer (dev ou leadDev).
-- 2023-02-16 - Le développeur envoie lui même en staging pour recette puis en production son travail (en prévenant les autres pour que l'équipe puisse pousser du travail en bonne intelligence).
-- 2023-02-16 - Si des informations manquent, pour des développements, ou que évolutions sont à signaler qui impactent nos partenaire c'est au développeur de se mettre en contact avec les personnes concerné. Cela peut-être le métier, ou éventuellement à des intervenants extérieurs à l'équipe (autres startup partenaires, PE, via mattermost, emails...)
+- 2023-06-19 - Développe les fonctionnalités (ou résolution de bug) selon leur priorisation par le métier lors des revues du backlog.
+- 2023-02-16 - Est responsable du bon maintient en condition opérationnelle des applications
+- 2023-02-16 - Est force de propositions sur les méthodes pour mettre en place ces fonctionnalités. Les décisions sont prises en pair, ou seul si le travail est fait seul.
+- 2023-02-16 - En cas de doute, le développeur (ou l'équipe de pair) doit contacter les membres de l'équipe qui peuvent le débloquer (dev ou leadDev).
+- 2023-02-16 - Le développeur envoie lui-même en staging pour recette puis en production son travail (en prévenant les autres pour que l'équipe puisse pousser du travail en bonne intelligence).
+- 2023-02-16 - Si des informations manquent, pour des développements, ou que des évolutions sont à signaler qui impactent nos partenaires, c'est au développeur de se mettre en contact avec les personnes concerné. Cela peut être le métier, ou éventuellement à des intervenants extérieurs à l'équipe (autres startups partenaires, PE, via mattermost, emails...).
 - 2023-02-16 - Fait monter les autres en compétences sur les sujets qu'il maitrise le mieux et qu'il se sent en capacité de le faire.
 
 ## Le role du lead
 
-- 2023-02-16 - est aussi un developpeur avec les régles associées
+- 2023-02-16 - est aussi un développeur avec les règles associées
 - 2023-02-16 - écoute les réclamations des devs
 - 2023-02-16 - est une référence sur la connaissance du produit et du métier
 - 2023-02-16 - est une référence sur la base de code, ou peut facilement pointer vers les gens qui ont la connaissance
-- 2023-02-16 - garant des pratiques et des standards de l' équipe
-- 2023-02-16 - porte parole de l'équipe. Notamment quand c'est pour défendre l'équipe si des deadlines impossibles sont demandées
+- 2023-02-16 - garant des pratiques et des standards de l'équipe
+- 2023-02-16 - porte-parole de l'équipe. Notamment quand c'est pour défendre l'équipe si des deadlines impossibles sont demandées
 - 2023-02-16 - tranche quand on arrive pas à trancher
 
 ## Processus de décisions de l'organisation de l'équipe (ce document)
 
-- 2023-06-02 - Ce document ne peut-être modifié qu'avec l'accord de l'équipe entière.
+- 2023-06-02 - Ce document ne peut être modifié qu'avec l'accord de l'équipe entière.
 - 2023-06-02 - Ajouter un membre de l'équipe se fait sous reserve d'un accord unanime.
 - 2023-06-02 - Conditions de départs
   - le membre de l'équipe qui souhaite partir peut partir
@@ -61,15 +61,16 @@
 
   1. Chacun donne son opinion
   2. Si la décision est unanime (unanimité) -> on adopte la décision
-  3. S' il y a un consensus (personne n'est contre) -> on adopte la décision
+  3. S'il y a un consensus (personne n'est contre) -> on adopte la décision
   4. Des gens pour / des gens contre
      - jusqu'à majorité 3 / 4 -> on adopte la décision
      - majorité 3 / 5 ou moins -> on adopte pas la décision -> et on prolonge les discussions
   5. droit de veto pour le lead dev
 
 - 2023-02-16 - Une fois la décision prise, la responsabilité est portée par toute l'équipe.
 
-- 2023-02-16 - Les prises de décisions doivent être documentées dans un ADR, et datées. Si on revient sur une décision, on refait un autre ADR. Comment la prise de décision a été faite doit être indiquée dans l'ADR.
+- 2023-02-16 - Les prises de décisions doivent être documentées dans un ADR, et datées. Si on revient sur une décision, on refait un autre ADR.
+- 2023-02-16 - Comment la prise de décision a été faite doit être indiquée dans l'ADR.
 
 ---