We need a new tool to centralize the display of all kanbans ( 1.7.X, modules, Side projects, etc.), to ensure a better team productivity and "ressource allocation".

To do so we need to use what has already been done with issuebot.

https://github.com/nikku/wuffle

Manque de clarté sur le fonctionnement d'une release : beta, RC, etc.

https://docs.google.com/document/d/1E52P85KZs8x2eTYlsGAoagYIIhnvyhuJ6lIaQ8_7J3Q/edit?usp=sharing

• add to the devdocs
• write an article
• publish article

• PostMortem meeting
• Write the report of the meeting

If we want to publicly communicate about it

• Write the article detailing the postmortem
• Publish the article

Quelles actions à mener pour la suite ?

Quoi ?
Comment ?
Pourquoi ?
Pour qui ?

Quel intérêt pour PS ?

Created by Coline Ginestet via monday.com integration. 🎉

Automatiser les actions manuels

• Mouvement des issues (à définir)
• Application des labels
• ... à compléter

Issue reported by @marionf

Quand on fait une nouvelle release, il faut:

• un dév applique le process
• un autre dév vérifie, grâce à une check-list à rédiger, que rien n'a été oubliée

Ex: vérifier manuellement que le Push API est bien à jour

Mettre à jour:

• https://devdocs.prestashop.com/1.7/basics/installation/system-requirements/
• https://www.prestashop.com/en/system-requirements

• Give best contributors a better visibility
• Contribution scoring

This project is related to the contributors website project.

Pour l'équipe core comme l'équipe produit

Tester Zenhub qui pourrait proposer les features manquantes à github

Issue reported by @TristanLDD

Toutes les issues doivent avoir une BV

Recherche et Analyse

• Veille BV in PM

• Journée produit avec réflexion sur la BV

• Test notation sur ProductBoard

• Formaliser une règle de calcul de la BV dans l'équipe Core

Mise en place

• Mettre en place la structure de notation (Gihtub, Productoard, Sheet - hebdo, mensuel, quotidien, etc.)

Ce sujet est là depuis toujours, mais il m'inquiète de plus en plus.

D'un côté on a toujours plus de réunions, et parfois (souvent?) nous n'y sommes invités "que" pour avoir l'information.

D'autre part, les réunions n'ont souvent aucun scope ou livrable et je sais que nous sommes tous d'accord là dessus.

On peut travailler sur les 2 sujets: je propose qu'on stocke dans un dépôt GitHub au format markdown les récap de chaque réunion qui concerne Core, Produit, Dev advocacy (antoine quoi) dans un premier temps.

On fait ça sur un mois et on regarde: qu'en pensez vous?

Lien du document: https://docs.google.com/document/d/1hRN2DSyDPScdld90h93Ce5nXaGbkElpBIC9d8u1pykg/edit?usp=sharing

Put the changelog tool online

Backlog commun entre issues ready et core

En lien avec l'idée des features teams

• format attendu ?
• pour quelles réunions ?
• Actions à préciser suite au ROTI

Avoir un sprint pour le BUILD
Avoir un kanban pour le RUN

Sur Addons ? Sur un site dédié ? Avec un CMS ? Avec un PrestaShop ?

Le débat est ouvert.

Mathieu propose qu'on les sorte si on trouve un moyen simple de les récupérer mais y aller petit à petit.

Pierre a ouvert une PR par rapport à ça + lien dans la doc "HowTo"

Dans l'article build on demande si besoin de les enlever dans les nightly, si besoin Jo s'en occupe. On ne le ferait pas tout de suite pour ne pas perdre trop de temps dessus.

Warning Node 8+ nécéssaire

ACTION : A creuser au retour de Pablo, on attend d'ici là - Core team

Faire un article sur Build pour expliquer notre décision, en amont de préférence - TBF

• Avoir le Go de Pablo
• Publier l'article et checker les retours
• Valider ce choix avec la communauté
• Retirer les assets de la source pour de bon
• Mettre à jour la doc contributeurs
• Modifier l'article pour annoncer la décision et renvoyer vers la doc -> #693
• Mettre en ligne l'article

On a 900+ issues actuellement, et ça n'arrête pas de monter.

Il faudrait regrouper des bugs ou groupes de bugs pour pouvoir les traiter.
Pareil avec les demandes de features.

This project aims at automatizing a certain number of tasks that are done manually today :

• move issues in their kanban according to the status of their pull requests
• synchronise status of issues which are in different kanbans
• add labels to issues and PR according to their status

The issuebot project uses Probot.

Nous avons désormais les tests E2E complets qui sont lancés chaque nuit avec un rapport des failures trouvées.

L'étape suivante est de surveiller chaque jour ce rapport d'erreur, réduire le nombre d'erreur à zéro et le garder à zéro. A voir quel process appliquer pour y arriver: mail automatique quotidien ? notifications dans slack ? dashboard visible sur une télé dans l'openspace ? génération automatique d'issues dans github ?

https://docs.google.com/document/d/1-KwJjyn91cMCt-21GX02qFrszKclkenAYrjvY6alSVA/edit?usp=sharing

Un dev module + 1 parrain core pour un check début et fin

Mettre en place un process pour établir les besoins de QA automation afin de s'assurer qu'il n'y a pas de problème de synchro

Pout tout avoir sur le dépo principal et pouvoir ajouter/prioriser les issues des modules dans le kanban

Sur les pull requests:

• Elles doivent être relier à une issue (Améliorer le BOT pour rendre cela obligatoire)
• Le titre doit être explicite
• La description et la partie tests doivent être claires

Sur les issues:

• Titre explicite (et non juste 500 error)
• Récapitulatif dans le premier commentaire pour expliquer clairement ce qu'il s'est passé et comment le reproduire (en cas de bug) ou quelle a été la décision fonctionnelle (en cas de feature)

Le consigner dans la devdoc

Issue reported by @ttoine