Réunion des dév' de Zeste de Savoir

Bonsoir,

Merci aux 8 participants de la réunion qui a duré tout juste 2 heures. En voici le compte-rendu (rédigée en groupe et mise en forme par @Aabu).

Petit point sur le projet (artragis)

« Je voudrais qu’on ajoute un petit point sur l’usage des projets, d’une part pour accueillir les nouveaux arrivants qui n’ont pas forcément eu les autres réunions pour savoir ça, mais aussi pour les formaliser car jusqu’à aujourd’hui c’était justement très… informel. »

3 projets utiles :

• « Triage des tickets pour débutant »
  • permet d’accueillir très facilement les nouveaux contributeurs avec des tickets prémâchés
• « Suivi des PR »
  • presque totalement automatique, néanmoins il faut ajouter chaque PR au projet
  • permet d’avoir une vision de l’état des PRs
• « Objectif v30 »
  • géré seulement par artragis, permet de voir les trucs prioritaires pour la prochaine version

Décisions

• marquer dans la description de "Objectif vXX" que la modification est réservée au Maintener (fait)
• dans « Suivi des PR », vider la colonne "fusionnées et cimetière" à chaque réunion des développeurs (environ tous les 2 mois)

Définir les navigateurs supportés

• Je trouve nécessaire de définir précisément les navigateurs que l’on supporte pour bien adapter le code CSS, le code JS ainsi que la configuration du serveur. Je propose de différencier :
  • les zones accessibles à tous les visiteurs (la lecture des contenus et du forum) où l’on souhaite une grande compatibilité pour rester dans le partage de la connaissance pour tous ;
  • les zones accessibles seulement aux membres (par exemple la rédaction des contenus) où l’on peut se permettre d’être compatibles seulement avec les navigateurs récents pour faciliter le développement du site.

Décisions :

• doctrine globale : Safari, Edge, Chrome, Firefox avec pour chacun les deux dernières versions + les versions à support étendu
• en bonus, support de navigateurs gagné à l’aide de scripts automatiques (genre préfixage de propriétés CSS)
• attention particulière à limiter les fonctionnalités modernes sur les pages de consultation
• sur les pages de rédaction, "best effort", tant pis si les navigateurs un peu vieux ne fonctionnent pas correctement

Discuter du Code de Conduite des Développeurs

• On a mis en place un Code de Conduite il y a plusieurs années et c’est à mon avis une bonne chose, mais je souhaite que l’on en discute aujourd’hui et que l’on se pose ces questions :
  • Quelle procédure mettre en place si l’un des contributeurs enfreint ce Code de Conduite ?
  • Faut-il prévoir des sanctions (blâme, avertissement…) ? Si oui, qui décide de ces sanctions ?

Décisions :

• les responsables du projet technique suspendent immédiatement les droits liés au projet technique en cas de manquement grave et flagrant au code de conduite.
• les membres du projet technique se réunissent ensuite pour décider des suites à donner, le cas échéant avec des représentants de l’association.

État du développement

• prochaine version corrective v29.1a (Situphen)
  • màj de Django prête
  • màj du watchdog de publication prête
  • si possible correction du bandeau very-top-banner
  • en même temps, redémarrage serveur (màj du noyau Linux et passage à 50 Go de stockage)
• prochaine version mineure v29.2 ou majeure v30 (artragis ?)
  • objectif : amélioration des outils de rédaction et de validation
  • quels tickets et quelles PRs à mettre en priorité ?

Discussion

• correction du bandeau very-top-banner pas prioritaire : ça attendra la prochaine version
• concernant le stockage des données sur le serveur : l’essentiel de la place est pris par les exports et les déchets des builds d’exports (logs latex, etc.), ce n’est maintenant plus nécessaire depuis que l’export est stabilisé ; les images des galeries prennent peu de place comparativement.
• pour les images le problème est plus l’utilisabilité de la galerie que de concevoir des systèmes pour économiser le stockage (génération de miniatures à la volée par exemple).
• fermer la PR sur "lintage shell" parce qu’elle n’est pas encore assez mature en l’état
• objectif v29.2 : amélioration de la page de création des contenus + màj de l’éditeur + zmd 9.1
• objectif v30 pour plus tard : refonte de la page de création des contenus

Divers

• fonctionnalité de partage de contenus non publiés : lien de partage, message d’avertissement comme quoi c’est non-validé, date de péremption finie (lien vers le ticket Github)
• accessibilité : renforcer le contraste en retravaillant les couleurs, accessibilité des unes,
• refonte de la page d’accueil et de la bibliothèque important dans le futur pour être plus ouvert aux visiteurs

Salut,

Ça fait maintenant deux mois qu’on s’est réuni et il s’est passé pas mal de choses ces dernières semaines ! Qu’est-ce que vous pensez de refaire une réunion bientôt pour faire le point ? Je pensais fin août ou début septembre en fonction des disponibilités de chacun.

Partant ! Je suis dispo après le 28 août inclut à coup sûr ; avant c’est pas dit.

Merci @Aabu pour cette bonne idée ! Comme d’habitude voici le petit sondage pour connaître les disponibilités de chacun et pouvoir décider d’une date.

D’après le sondage, trois dates se dessinent :

• le 31 août (7 oui, 1 non) ;
• le 2 septembre (6 oui, 2 peut-être) ;
• le 3 septembre (6 oui, 2 peut-être).

Du coup, on fixerait quelle date ? J’ai l’impression que ça dépend surtout de si @artragis et @Stalone arrivent à se rendre disponibles pour le 2 ou le 3.

Je laisse @artragis fixer sa préférence. Je ne connais pas plus mes disponibilités qu’au moment de remplir le sondage.

Comme je l’ai dit mon seul pb pour mercredi et jeudi c’est que je suis pas sûr d’être à l’heure.

Mais je serai présent l’un comme l’autre.

Je propose qu’on fixe la date au 2 septembre à partir de 19h30, ça devrait convenir à tout le monde !

Je pense qu’il serait intéressant de :

• faire un tour des PRs ouvertes : est-ce que l’auteur bloque sur quelque chose ? faut-il relancer l’auteur ? etc
• discuter des changements graphiques à venir avec les PR de @Amaury : normalisation du des couleurs CSS notamment
• de la prochaine version : est-ce qu’on fait une petite version mineure ou on attends les grosses PRs à venir pour une version majeure ?
• du passage aux courriels de Gandi : notamment des soucis rencontrés par @Amaury et moi, mais aussi de l’adresse technique@zestedesavoir.com à venir

Avez-vous d’autres points à aborder ?

Bonjour,

J’aimerai discuter d’un changement sur le tableau "Suivi des PR". Ça sera vite fait de demander des avis à chaud.

Mon constat est que la colonne "En attente de retours" est très peu utilisée et finalement, il n’y a que des PR en hibernation, saupoudrées de quelques PR qui pourraient rejoindre les autres en attente d’avis extérieurs.

Sur le tableau de suivi des PR, je propose donc de fusionner "En attente de retours" et "En attente de QA", ainsi que renommer "En attente de QA" en "En attente de QA ou retours". Les PR de la colonne disparue serait déplacées dans "En attente de QA ou retours" ou dans "En développement".

C’est un changement important, tu devrais ouvrir une ZEP pour ça.

Bonjour,

Cela va faire deux mois depuis la dernière réunion donc je propose que l’on choisisse une date pour la prochaine réunion. Merci donc de remplir ce sondage avec vos disponibilités à venir !

Pour le moment, trois dates se détachent du sondage : le jeudi 12 novembre, le jeudi 19 novembre et le dimanche 22 novembre. J’invite ceux qui n’ont pas encore voté à le faire !

Les disponibilités du sondage n’ont pas changé, sauf pour ma part je ne peux pas le jeudi 12 novembre, donc la prochaine réunion à propos du développement technique de Zeste de Savoir aura lieu le jeudi 19 novembre dimanche 22 novembre à partir de 19 heures ! Comme d’habitude, la réunion aura lieu sur notre serveur Discord dans le salon #développement-de-zds ouvert à tout le monde. N’hésitez pas à dire si vous souhaitez aborder certains points en particulier, je publierais l’ordre du jour quelques jours avant.

@Amaury vient de mettre à jour ses disponibilités et il n’est pas disponible le jeudi 19 donc on décale la réunion au dimanche 22 novembre !

Bonjour,

Je viens vous proposer un premier jet d’ordre du jour pour la prochaine réunion ! Il y a pas mal de chantiers en cours (cela se voit avec les 38 PR ouvertes) et je pense qu’il serait bien de discuter de chaque chantier et les prioriser pour avancer sans trop se marcher dessus.

• (Actualité 1) Migration de Travis CI vers Github Actions
  • Travis CI a très récemment modifié sa tarification, dans la plus grande discrétion, en limitant drastiquement son offre gratuite pour les projets open-source à 1000 minutes par mois. Tant est si bien que nous sommes bloqués car nous consommons plus que 1000 minutes par mois et dès lors Travis CI ne fonctionne plus à l’heure actuelle. @Situphen a envoyé un courriel à Travis CI pour essayer d’avoir quelques crédits supplémentaires mais il va nous falloir migrer dans les jours et semaines qui viennent sur Github Actions ou une autre solution alternative.
• (Actualité 2) Destinée des comptes créés via Facebook et Google

  • Google nous écrit ça sur la boîte de l’asso (la graisse est d’eux) :

    We are writing to let you know that Google will discontinue support for sign-ins to Google accounts from embedded browser frameworks, starting January 4, 2021.

    We have detected the use of an embedded browser framework with one or more of your OAuth clients that may be blocked on or after January 4, 2021. Please review your use of Google Account authorization flows in the following Google OAuth client IDs and make any required changes before January 4, 2021:

    → Zeste de Savoir

    Ils ajoutent ces détails : https://developers.googleblog.com/2020/08/guidance-for-our-effort-to-block-less-secure-browser-and-apps.html

  • Il va falloir réfléchir à notre plan d’action concernant ce que nous dit Google, mais plus globalement l’avenir de la connexion via les réseaux sociaux. Peut-être serait-il bien en premier lieu de ne plus permettre la création de comptes depuis les réseaux sociaux, avant de réfléchir à une transformation des comptes existants créés via les réseaux sociaux en comptes standards.

• (Chantier 1) Accessibilité et normalisation graphique
  • @Amaury a entamé ce gros chantier qui consiste à donner une plus grande cohérence graphique au site web grâce à la création de normes graphiques : une palette restreinte de couleurs, tailles de polices, longueurs, ombres et arrondis. Par la même occasion, il travaille sur l’accessibilité des couleurs pour les visiteurs du site web, c’est-à-dire s’assurer que le contraste entre la couleur du texte et celle du fond est suffisant pour naviguer sur le site web sans se faire mal aux yeux.
  • Un Compagnon d’interface a été créé pour faciliter l’appropriation de ces nouvelles normes et donc leur respect par les développeurs
  • (v30) La première étape de ce chantier est la PR 5922 « Normalisation graphique et accessibilité » qui est bien avancée mais doit être fignolée. Je pense qu’il ne faut pas viser la perfection sur cette PR car sinon elle va rester ouverte des mois. Je propose qu'@Amaury la fignole du mieux qu’il peut, puis qu’on la fusionne et qu’on corrige au fur et à mesure les quelques coquilles qui resteront. Je propose que cette PR fasse partie si possible de la v30. Il est probable que les membres du site découvrent quelques rares coquilles et si c’est le cas rien ne nous empêchera de les corriger avec une version corrective v30a.
  • (après v30) Les étapes suivantes sont l’amélioration graphique du site web dans son ensemble (travail qui a très doucement commencé avec la PR 5835 « Amélioration graphique et accessibilité ») ainsi que la refonte de la page d’accueil. À mon avis ce ne sera pas prêt pour la v30 et je pense qu’il est bon de laisser du temps de réflexion sur ces changements très radicaux.
• (Chantier 2) Amélioration de l’interface de rédaction
  • Ce chantier a déjà commencé avec plusieurs petites modifications notamment l’allègement du formulaire de création de contenu. Néanmoins il n’est pas fini ! Il y a encore plusieurs tickets d’ouverts dans le projet Github « Amélioration continue de la rédaction » notamment l’ajout d’une page « Tableau de bord » pour mieux s’y retrouver que dans la barre latérale et trouver une façon de mieux différencier les différentes versions d’un même contenu (brouillon, bêta, publique…).
  • (v30) Je pense que dans premier temps on devrait regarder parmi ces PR ouvertes celles que l’on peut facilement finir et fusionner : la PR 5804 « Modification des titres et sous-titres de contenu "in place" », la PR 5920 « Déplace le choix des catégories dans un formulaire indépendant », la PR 5940 « Historique des événements sur un contenu ».
  • (après v30) Je pense qu’il faut remettre à un peu plus tard l’ajout de la page « Tableau de bord » car rien n’a été commencé et cela va demander pas mal de travail !
• (Chantier 3) Nouvel éditeur
  • Soyons honnête, le passage à l’éditeur EasyMDE ne s’est pas passé comme prévu ! Je pense que l’on a fait le bon choix de permettre la coexistence de l’ancien éditeur (dit éditeur historique) et du nouvel éditeur (dit éditeur expérimental). Néanmoins, on ne va pas pouvoir maintenir indéfiniment deux éditeurs, leur coexistence double la charge de travail des développeurs pour vérifier que tout fonctionne comme il faut. Il va nous falloir dans un premier temps mettre le nouvel éditeur en tant qu’éditeur par défaut tout en laissant l’ancien éditeur accessible, puis plus tard supprimer l’ancien éditeur. Dans cette optique, il faut nous assurer que le nouvel éditeur comporte toutes les fonctionnalités proposées par l’ancien éditeur (ce qui n’est pas le cas actuellement car il manque à minima les smileys et les abréviations) et qu’il n’y a plus aucun bug rencontré (notamment de bugs entraînant la perte du contenu que l’on est en train d’éditer).
  • (v30) Je propose pour cette version de laisser l’éditeur historique par défaut mais de travailler pour consolider le nouvel éditeur. Je pense notamment qu’il faut passer à la version 2.13.0 de EasyMDE et aller à la chasse aux bugs entraînant la perte du contenu que l’on est en train d’éditer. C’est nécessaire si on veut que les auteurs aient confiance dans l’éditeur qu’on leur propose.
  • (après v30) Il faudra ajouter les smileys (travail entamé avec la PR 5728 « Ajout de quelques emojis sur le nouvel éditeur ») et les abréviations à l’éditeur… si on choisit de rester avec EasyMDE. Car @Amaury a entamé une réflexion sur l’ergonomie de l’éditeur (avec la PR 5910 « Améliorations de l’UX de l’éditeur » et il est peut-être préférable d’utiliser directement CodeMirror plutôt que la surcouche EasyMDE sur laquelle on rajoute nos modifications à nous !
• (Chantier 4) Préparation du passage à Django 3.2 LTS et mise à jour délicate des dépendances
  • Nous utilisons actuellement Django 2.2 LTS qui sera maintenue jusqu’en avril 2022 donc il n’y a pas d’urgence mais j’ai déjà commencé à préparer la transition vers Django 3.2 LTS qui va sortir en avril 2021. L’idée est simple : lancer en local Zeste de Savoir avec Django 3.0, voir les erreurs qui sont retournées, les corriger et répéter l’expérience avec Django 3.1 puis Django 3.2 LTS. Il faut s’occuper de deux choses : mettre à jour notre code pour qu’il soit compatible avec les nouvelles versions et vérifier que nos dépendances soient compatibles avec les nouvelles versions. Pour notre code, c’était très simple pour Django 3.0 (voir la PR 5952 « Prépare le terrain pour Django 3.0 ») et je pense que cela ne devrait pas être beaucoup plus compliqué pour Django 3.1. Pour nos dépendances, ce n’est pas la même affaire ! Il va falloir mettre à jour les paquets django-uuslug et python-slugify qui s’occupent de la génération des slugs, c’est-à-dire la transformation de « C’est la vie » en « cest-la-vie », sauf que dans les nouvelles versions « C’est la vie » devient « c-est-la-vie » et que si on gère mal ce petit changement ça peut potentiellement casser des contenus. Bref, il va falloir être prudent et c’est pourquoi j’ai commencé à réfléchir à ça avec la PR 5951 « Mise à jour des dépendances qui gèrent les slugs ». Il y a d’autres dépendances que nous n’avons pas mis à jour par manque de temps et qui risquent de poser soucis dans le futur : elasticsearch et elasticsearch-dsl (voir la PR 5957 « Migration vers ElasticSearch 7 ») ainsi que Faker et factory_boy (si quelqu’un aime les casses-tête) ! Je ne mets pas d’objectif de version mais ce sera un passage nécessaire un jour ou l’autre.
• (Question 1) Comment se débrouiller pour fusionner la PR sur Black sans trop de soucis ?
• (Question 2) Étant donné le travail en cours pour se passer de jQuery dans certains fichiers Javascript existants, est-ce que l’on ne devrait pas interdire l’utilisation de jQuery dans les nouveaux fichiers Javascript ?
• En fonction du temps qu’il nous reste, il peut être bien de passer rapidement en revue les PRs ouvertes pour faire un état des lieux comme d’habitude.
• Questions et remarques diverses

N’hésitez pas à me dire si j’ai oublié quelque chose mais je pense avoir fait le tour là ! Je pense qu’il est bon de prévoir au moins 2 heures pour cette réunion si on aborde tous les points.

Édition 1 : Ajout du Chantier 4
Édition 2 : Ajout de l’Actualité 1
Édition 3 : Ajout de l’Actualité 2

Bonsoir,

Petit rappel : la prochaine réunion aura lieu demain soir à 19 heures !

Merci pour le compte-rendu !

L’ordre de fusion des PR est donc le suivant, selon moi, pour la version 30.

• 1) #5994 – Migration de la CI de Travis à GitHub Actions — Prête, revue nécessaire, fusion par un administrateur nécessaire car Travis sera toujours là (sauf à le rendre non-obligatoire avant fusion).
• 2) (Retrait de Travis de la configuration du dépôt par @Situphen)
• 3) #5964 – Utiliser black pour formater le code Python — Prête, QA nécessaire.

Ensuite, tout peut être fait dans l’ordre voulu, notamment (liste non exhaustive)…

• Toutes les PR de firm1 retirant jQuery.
• #5920 – Déplace le choix des catégories dans un formulaire indépendant
• #5922 – Normalisation graphique et accessibilité
• (Éventuellement) #5944 – L’installeur en version complète ne persiste plus définitivement le PATH du moment de l’installation du JDK

Concernant #5922 – Normalisation graphique et accessibilité, elle apporte des modifications prémices à…

• #5960 – Nouvelle tête pour les messages
• #5996 – Corrige le style et la semantique lors de la desinscription