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

a marqué ce sujet comme résolu.

Bonne remarque concernant les protections vis-à-vis des attaques par fichiers malicieux. Concernant l’autre point, c’est juste si on parle d’un ré-hébergement ; pas si on parle d’un proxy, à ma connaissance — ce qui est également envisagé.

Et, n’a-t-on pas déjà le problème depuis des années vu que les PDF des contenus intègrent de telles images ?

Amaury

Je pense que pour un proxy ça passe – l’idée c’est surtout que si l’auteur de l’image la modifie ou supprime sur son hébergement source, la modification soit répercutée chez nous aussi.

Pour la question des PDF, ça me parait acceptable de demander à ce que les ressources des contenus soient hébergées sur ZdS, ne serait-ce que pour garantir la pérennité de leur affichage. Je suis moins convaincu pour les ressources autres (contenus des MP, des forums, des biographies, avatars…)

Et merci pour l’explication sur micromark. C’est assez infernal cette histoire de Markdown – on a un effort démesuré dessus depuis le début, entre les problèmes de la versions Python et maintenant la migration de la version JS. Mais j’imagine qu’on a pas tellement le choix.

+3 -0

Voici le compte-rendu de la réunion du 12 décembre. Veuillez m’excuser pour le délai.

La réunion a eu lieu à l’heure. Nous étions 5 à 6.

Disponibilités et motivations des contributeurs présents

  • Situphen : bonne motivation ; disponibilité faible jusqu’à février mais ensuite c’est bon.
  • Aabu : disponibilité passive mais présente quand même.
  • Amaury : peu actif depuis un an, mais regain de disponibilité après janvier normalement.
  • artragis : pointilliste du code, en fait un peu de temps en temps, motivation qui revient notamment sur les statistiques et les quizz.
  • philippemilink : motivation toujours là, pointilliste en terme de temps, dispo par périodes.

Problématique de l’absence à long terme de @Stalone

@Stalone n’est presque plus contactable pour raisons personnelles. C’est l’actuel mainteneur principal (et quasi exclusif) de zmarkdown (zmd). S’il a indiqué rester disponible pour la maintenance de zmd, le signal envoyé reste un peu dangereux, et il serait d’un bon sens que de trouver un·e autre mainteneur·euse. Et même au delà de cela, n’avoir qu’un seul mainteneur n’est jamais une bonne idée.

Les actions suivantes ont été envisagées en réaction à l’absence de @Stalone.

  • Obtenir les droits npm pour une nouvelle personne.
  • Trouver une personne intéressée par zmarkdown pour servir de mainteneur·euse de secours. @ache, ou quelqu’un parmi les utilisateurs·trices tiers de zmd ?
  • Informer les pépiniéristes que cette partie du projet se fera avec peu de support, si jamais ils s’attaquent à cette partie.
    • Les étudiant·es ont été prévenu·es et ont décidé de laisser tomber le projet zmd, se concentrant sur le reste.

État des lieux des PRs

Les autres PR sont sans état discuté, ou avec un état évident en lisant la PR.

Discussion et organisation concernant les projets étudiants

Les projets des étudiant·es ingénieur·es de l’ENSEIRB-MATMECA s’échelonnent en plusieurs étapes :

  • analyse du besoin et écriture d’une spécification précise, jusqu’à janvier ;
  • implémentation, entre janvier et avril.

Il a été proposé aux étudiant·es de relire leurs spécifications, qu’iels doivent rendre avant de passer à la partie implémentation, et qui est notée. Il faudra juste le faire avec suffisamment de délai pour laisser le temps de fournir des retours.

Quatre Trois projets sont prévus.

  • Migration de zmarkdown vers micromark Suite à l’absence de @Stalone, il a été décidé de ne pas traiter ce projet.
  • Quizz & sondages : comme la partie quizz a été quasiment terminée par @artragis, le travail se limitera à étendre l’implémentation des quizz pour gérer des sondages (sur le forum), et à consolider l’implémentation existante des quizz.
  • Applications du groupe de travail sur les publications : ce sont plein de petites tâches, explicitées sur le lien ci-avant.
  • Module de recherche : il est impossible de passer à Python 3.10 ou supérieur à cause d’une incompatibilité du module Python qui fait le lien avec Elastic Search. On leur a transmis cet article qui fait le point sur la recherche de Zeste de Savoir, pour leur servir de base. Vu l’état actuel du système et la complexité de migrer, il sera sans doutes mieux de juste repartir de zéro avec une utilisation moderne d’Elastic Search 8.

Depuis cette réunion, les étudiant·es ont également discuté entre eux, et voilà ce qui en est sorti.

Git workflow

Pour les QA : mettre des messages explicites et si graphique, mettre des captures d’écran. Pour les grosses PR, il est important de mettre des bons messages de commit pour suivre l’avancement du travail.

Information suite à la réunion des dev ZdS

Abandon du travail sur zMarkDown

Faire tourner le site pour la version 3.10 ne marche pas

  • Migration de ElasticSearch
  • Quels sont les avantages, analyse de l’existant
  • Tâche principale

Quizz et sondages

Travail préliminaire déjà fait, il reste les sondages à faire et la QA de la PR au niveau fonctionnel (si fonctionnalité manquante à nous d’implémenter)

Points d’action

  • Finir toutes les PR + QA pour dimanche 1er janvier
  • Cahier des charges :
    • ElasticSearch
    • Organisation des publications
    • Quiz et sondage
Victor Lohézic sur Discord

Idées pour une meilleure gestion des tickets

L’idée est de créer un projet « Suivi des tickets » calqué sur le projet « Suivi des PR ». Ce projet a été créé depuis.

  • On commence par tout mettre dans À trier.
  • Autres catégories :
    • À reproduire
    • À discuter
    • Quand les poules auront des dents

À ne pas confondre avec le tag Facile qui est là pour prémâcher et accueillir un ou une contributeur·trice.

Idées pour l’intégration de Yuzu au site

Yuzu est un projet mené par @Amaury avec la participation de plusieurs autres personnes (principalement @Moté, ainsi que des avis pertinent de @sgble, @Situphen et @Melcore, entre autres) de refonte plus profonde de l’interface de Zeste de Savoir.

Pour le moment, Yuzu n’existe que sous la forme de maquettes.

Une idée a été proposée afin de pouvoir un jour voir ces idées implémentées, sans devoir attendre que tout soit fait d’un coup, rendant une éventuelle PR très délicate à gérer.

  1. Finir de concevoir les parties communes à toutes les pages, nommément l’en-tête et le pied de page. En effet, une nouvelle en-tête a été conçue, et il y a des plans pour reprendre l’organisation des menus de pleine page pour les rendre plus simples à comprendre et plus attrayants. Un aperçu est donné ci-dessous (ignorez la différence de couleur).

    Haut du site, déconnecté. On voit le logo de Zeste de Savoir, puis deux menus suivi d'une petite flèche vers le bas : “Bibliothèque”, et “Discussions & entre-aide”. Aligné à droite, un champ de recherche aligné au reste avec une petite loupe et un label “Rechercher Neurosciences, Python…”, et un lien “Nous rejoindre” suivi d'une petite flèche vers le bas.
    Déconnecté·e
    Haut du site, connecté. La même chose que la précédente image ci-dessus, mais à la place du lien “Nous rejoindre” tout à droite, deux icônes : une avec un panneau attention, et l'avatar de la personne connectée suivi d'une petite flèche vers le bas. Chacune de ces icônes ont un cercle rouge contenant un nombre, en haut à droite de chacune, passant légèrement par dessus et représentant le nombre d'éléments non-lus : respectivement neuf et une.
    Connecté·e

  2. Implémenter, dans une PR, les nouvelles en-têtes et pieds de page. Ces éléments étant communs à toutes les pages, il est plus simple de le faire d’un coup.

  3. Créer un système avec deux feuilles de style distinctes : une avec le nouveau design, réécrite de zéro ou presque, et l’ancienne. Le système de construction compilera les deux, vers des fichiers distincs.

  4. Créer un système de feature-flag afin de charger par page la bonne feuille de style, en utilisant l’ancienne par défaut. Ainsi, il sera possible de reprendre le site progressivement, page par page, en commençant par des pages plus mineures.

Merci à tous d’avoir contribué à ces discussions. N’hésitez pas à ajouter ce que j’aurais pu oublier (en réponse ou directement si vous avez les droits), et à répondre si vous avez quelque chose à ajouter ou un avis à donner ! (Préférez les sujets dédiés aux différents projets plutôt que celui-ci, cependant, afin de garder tout cela bien organisé.)

+3 -0

Coucou les devs,

Cela fait quelques mois que l’on n’a pas fait de réunion. J’ai l’impression que le projet étudiant avance plutôt bien vu les messages sur Discord mais en lisant le compte-rendu de la dernière réunion j’ai l’impression que d’autres sujets n’ont pas avancé. Je propose donc l’habituel sondage des disponibilités, avec beaucoup de dates car le pont de l’Ascension et les événements scientifiques du week-end suivant risquent de compliquer le choix de la date.

+0 -0

Oui, j’y pensais que ce serait bien de faire une réunion bientôt, mais je suis assez chargé en ce moment… Merci Situphen de prendre l’initiative.

Y a deux points que j’aimerais aborder :

  • synthèse et retours sur le travail réalisé par les étudiants
  • prochaines versions de ZdS (j’ai dans ma tête un plan assez précis des prochaines releases, j’aimerais bien en parler)

Ce serait bien de faire la réunion après le 15 mai : les étudiants soutiennent leur projet le 16 mai donc leurs contributions seront officiellement terminées à ce moment-là.

+3 -0

Voici le compte-rendu de la réunion.

Étaient présents : Aabu, artragis, Situphen, moi-même et d’autres ont passé une tête.

Retour sur le projet étudiant

Pour rappel, le sujet qui en parle.

Travail réalisé :

Prochaines étapes pour que tout soit mergé :

  • Faire une revue de code sur la recherche, faire les script Ansible pour installer Typesense
  • Travail nécessaire pour les quizz, cf plus bas

Proposer un tel projet l’année prochaine ?

  • Mieux découper les tâches pour proposer des jalons intermédiaires mergeables
  • Avoir déjà les idées au clair sur ce qu’on veut de notre côté

Roadmap des prochaines releases

  • Une version mineure 30.5 avec ce qu’on a actuellement dans la branche dev et mise à jour des dépendances
  • Puis une version majeure avec le nouveau moteur de recherche et les quiz.

Quiz

Essayer d’avoir un système de statistique minimal dans la première version des quiz qui sera mergée.

Pour éviter le problème de l’absence de statistiques tant que personne n’a répondu, afficher les statistiques directement sur le contenu, dans la version privée de l’auteur, à côté des quiz, sans page dédiée (dans une premier temps, tant que zmd n’a pas de fonctionnalité pour nous donner les quiz dans un contenu).

Rapide mot sur l’état de la maintenance des serveurs

Situphen a de nouveau accès au serveur de prod (il avait toujours accès à celui de bêta).

Globalement ça va bien. Le mécanisme de sauvegarde fonctionne bien et le stockage occupé par les sauvegardes se stabilise. Le point qui devient relativement urgent est la mise à jour de Debian 10 vers Debian 11 pour ne pas prendre trop de retard (Debian 12 arrive dans quelques mois). Un autre point important est de rapatrier Munin sur nos serveurs.

État du développement de zMarkdown

Pas vraiment de nouvelles sur ce point.

Ne pas oublier de récupérer les droits NPM.

Que faire des comptes très inactifs

cf ce sujet.

Ne vaut pas vraiment la peine de passer du temps sur cette question. Les comptes pas activés ne sont pas si nombreux et ne gênent pas (n’occupent pas vraiment d’espace de stockage).

Divers

Mise à jour des membres des équipes GitHub et de ceux qui possèdent la casquette Équipe technique sur le site.

Revue des PRs ouvertes.

Faire des réunions de devs plus souvent, plus courtes. Prochaine réunion envisagée fin juin / début juillet.

+2 -0

Si vous n’avez pas besoin de conserver l’historique, NetData https://www.netdata.cloud/ remplace très bien Munin, en beaucoup plus simple, léger et complet, surtout maintenant que par défaut il conserve plus qu’une poignée d’heures de données.

PS : pour garder des séries vraiment longues (> 1 mois) il faut peut-être passer par une configuration spécifique ou un moteur de stockage supplémentaire. Tout est détaillé dans la documentation, elle-même facile à trouver puisqu’elle est directement liée dans l’interface si on essaie d’afficher des données avant le début de la série – ce qui est toujours le cas sur une installation fraiche, par définition.

+3 -0

Voici le compte-rendu de la réunion.

Présents : Aabu (arrivé en cours de route), Melcore, Situphen et moi-même.

Refaire un projet étudiant à la rentrée ?

Est-ce qu’on propose à nouveau un projet à des étudiants pour contribuer au code de Zeste de Savoir, comme on l’a fait cette année ? La réponse penche plutôt vers le négatif, pour plusieurs raisons :

  • on n’a toujours pas mergé une partie du travail réalisé par les étudiants (la recherche et les quizzs) ; ce serait bien que ce soit mergé avant de proposer un nouveau sujet !
  • il faut avoir des tâches à proposer. Cette première expérience montre qu’il faut proposer un sujet avec un objectif clair et bien défini pour que le projet fonctionne bien (par exemple la recherche ou les quizzs) ; les tâches un peu plus floues, où nous-mêmes ne sommes pas complétement sûrs de ce que nous voulons, fonctionnent moins bien (par exemple la réorganisation des publications).
  • finalement, ce sera compliqué pour moi de pouvoir jouer le rôle du client…
ZMarkdown

Une faille de sécurité a été découverte dans la génération des PDFs. Une nouvelle version de ZMarkdown la corrigeant a été publiée, mais n’est pas encore déployée sur le site de Zeste de Savoir. Il faut mettre à jour la PR qui met à jour zmd et vérifier que les contenus évoqués sont correctement exportés en PDF. En attendant, la génération de PDF est désactivée pour les billets (tutoriels et articles passent par une validation, donc les validateurs peuvent repérer les tentatives d’exploitation de la faille avant de publier le contenu).

Situphen a proposé de développer une fonctionnalité dans zds-site qui permettrait de ne générer les PDFs des billets seulement une fois qu’ils sont mis en avant (action réalisée par un membre de l’équipe, qui peut donc vérifier que le billet ne tente pas d’exploiter la faille). Personnellement, j’ai l’impression que ce serait contourner la racine du problème, mais Situphen rétorque qu’on trouvera toujours des failles dans la génération des PDFs et que ça pourrait permettre de déstresser un peu ceux qui ont accès aux serveurs lorsqu’il est nécessaire de rapidement désactiver la génération des PDFs…

Situphen a obtenu les droits sur l’organisation NPM.js qui contient ZMarkdown et tous ses sous-paquets.

Serveur Matomo

Tout est dit là.

Serveur de bêta / Scaleway comme hébergeur

L’offre sur laquelle fonctionne le serveur de bêta est en fin de vie et il est nécessaire de passer à une nouvelle offre. Seulement, chez Scaleway, pour avoir une offre avec les mêmes caractéristiques, ça coûterait deux fois plus cher que ce qu’on paie actuellement (c’est un résumé rapide du sujet du forum).

On (tout du moins, Situphen et moi) avons décidé qu’il fallait donc trouver un autre hébergeur. On se donne jusqu’à fin août / début septembre pour évaluer les possibilités, on prendra une décision lors de la prochaine réunion des dév’s (qui sera bien-sûr soumise à l’approbation du conseil d’administration de ZdS ;) ). On changera d’hébergeur dans un premier temps le serveur de bêta, et à terme sans doute aussi le serveur Matomo.

Migration des boîtes e-mail

Actuellement, nous avons 4 boîtes e-mail (association, communication, evenements et technique), toutes hébergées chez Gandi, inclues dans notre offre. Gandi a récemment revu sa politique tarifaire vis-à-vis des boîtes mails : il va falloir bientôt payer 3,59 €/mois/boîte.

Melcore doit se renseigner s’il est possible que dans le cadre du programme de soutien de Gandi envers de ZdS, Gandi ne nous fasse pas payer ces boîtes e-mails. Si ce n’était pas possible, il faudrait essayer de trouver un fournisseur de boîtes mail moins cher et il serait sans doute possible de n’avoir besoin que d’une boîte (communication et evenements peuvent être des alias de association et technique peut (re)devenir une liste de diffusion). Auto-héberger le service de mail est plutôt exclu.

Plan pour la prochaine version de zds-site

La version 30.5 Kresnik a été publiée et mise en production dimanche dernier.

Une fois que la PR changeant le moteur de recherche sera fusionnée (je travaille lentement dessus), on pourra envisager de sortir la version 31. Il serait bien que cette version inclut également les PRs actuellement ouvertes et en attente de QA.

Divers

Traditionnel passage en revue des PRs ouvertes.

Prochaine réunion prévue fin août/début septembre.

Bonnes vacances d’été ! :soleil:

+3 -0

Puisque les principales personnes impliquées dans le développement de ZdS ont répondu au sondage, je pense qu’on peut le clôturer et j’annonce qu’on fera la réunion le jeudi 7 septembre à 20h.

D’ici là, n’hésitez pas à compléter les points à aborder dans le pad. Et si vous avez le temps, ce serait bien de regarder quels hébergeurs peuvent être considérés comme alternative à Scaleway (voir le sujet correspondant).

+1 -0

Voici le compte-rendu de la réunion !

État d’avancement de la PR sur Typesense

  • Relecture du code des étudiant·es par PM, petites modifs au fur et à mesure, refacto, “coup de fraîcheur sur le code” ; reste 2–3 fichiers à relire (assez gros, mais ça devrait aller)
  • Les étudiant·es ont ajouté des filtres, mais ergonomiquement y’a encore un peu de travail
  • Il faudra quelqu’un d’autre pour la QA
  • Fini pour la fin de l’année ? (Sans engagement)

État d’avancement de la PR sur la mise à jour de ZMD

  • Difficile à tester de peur des régressions (lors du dernier test, c’était le cas)
  • Ça a avancé côté zmd, beaucoup même. Un décalage de plus en plus grand avec la prod de ZdS.
  • Merger vers 11.3.0 sans être trop regardants sur la rétrocompatibilité, quitte à la gérer après coup au cas par cas
  • Faire une liste de contenus à regénérer en PDF dont on sait qu’ils ont été problématiques, avec un suivi dans le temps (pour quelles versions de zmd ça marchait, ou non ?) pour pouvoir les utiliser comme témoin afin de surveiller d’éventuelles régressions (déjà quelques exemples dans la conversation de la PR
  • Idéalement, il faudrait regénérer tous les PDF sur la bêta et comparer les PDF page à page avec un script (rien n’est censé changer). Mais une sous-liste avec une variété de publications serait déjà un bon début.
  • (Adobe a géré la migration de grid-tables vers micromark. Une grosse épine retirée du pied.)

Génération automatique des versions PNG des clémojis

Lié à la PR #6373)

  • Il faut des versions PNG car certains lecteurs d’epub ne gère pas le SVG.
  • A312 avait proposé de les ajouter au dépôt mais les autres sont pas fan, pour éviter la duplication. On serait plutôt en faveur d’un script de conversion qui transforme les SVG en PNG à la demande.
  • Script (16 lignes) de déploiement basé sur cairosvg
  • Quelques défauts pour les animations, mais pas grave, ce sera mieux que rien
  • Mettre la génération des SVGs en PNGs dans la commandemake build-front et ensuite on ajoutera dans les scripts Ansibile de déploiement.

Relancer le script de @Quarante-Trois pour avoir les versions Clem’ des nouveaux émojis à visage sortis depuis ? Il y en a pas mal.

  • On parle du remplacement des smileys Unicode par leur équivalent Clem, en se basant sur les Twemojis ; par exemple : 🤔 🙃 😬 😨 🤫
  • Il y a pas mal de nouveaux émojis qui n’ont pas eu leur équivalent Clem généré par QuaranteTrois, tel que 🫣 😶‍🌫️ 🫡 🫠 🫥 🫤 🫨 🥱, et plein d’autres
  • Le script à relancer se trouve ici
  • A priori c’est zmd qui fait la conversion. Vérifier qu’il n’y a rien à reconfigurer de ce côté.
  • Créer un ticket pour y penser.

Changement du serveur de bêta (sujet de référence)

On teste PulseHeberg pendant un mois ou deux (ou trois) pour voir (STOR-4 car la STOR-2 serait un peu juste), pour la bêta, et on avise ensuite.

Ce point a été mis à l’ordre du jour de la réunion du Conseil d’Administration du lundi 11 septembre pour validation.

Nouvelles de l’offre mail de Gandi

Préparation d’Hacktoberfest

Pour rappel, Hacktoberfest est un événement annuel organisé par DigitalOcean et incitant à la contribution aux projets open-source, dans la lignée des défis d’octobre (Inktober pour le dessin, writober pour le texte…), mais adaptée à la contribution de Pull Requests ou Merge Requests.

Cette année, il n’y a plus de récompense de tshirts pour celles et ceux dépassant 4 PR/MR, mais il y aura des récompenses numériques et des arbres plantés1. Plus précisément, 50k arbres seront plantés pour les 50k premiers·ères à faire une PR complète et validée ; tout le monde aura comme récompense un badge numérique qui évoluera en fonction de son avancement (via Holopin). Il y aura aussi quelques goodies de sponsors pour les plus prolifiques.

  • Comme d’habitude : le billet, repris de l’an dernier, etc.
  • Tickets faciles à préparer (5 pré-mâchés au moment de la réunion ; 6 à pré-mâcher)
  • Faire de la promo pour Hacktoberfest par la com’

Programmation de la prochaine réunion

Début novembre, après Hacktoberfest (on pourra ainsi en faire un compte rendu).

Passage en revue des PRs ouvertes

Il y a actuellement 22 PR ouvertes.

Avancement de Yuzu (nouvelles maquettes)

J’ai un peu avancé, notamment niveau direction artistique, polices (avec Marmelad), différenciation des contenus validés ou non, et design des PDF.

Des remarques ont été faites sur la page de garde des PDF, la jugeant trop terne. Un bleu plus sombre serait peut-être bienvenu, à tester.

La maquette est consultable en ligne.

  1. Même si, bon.↩
+5 -0

Voici le compte-rendu de la réunion.

Présents : Aabu, Amaury, k-lipschitzienne (arrivé en cours de route), Situphen et moi-même.

Retour sur le Hacktoberfest 2023

Tout est dit dans le retour qu’a fait Aabu sous le billet qui annonçait Hacktoberfest 2023.

À faire : communiquer aussi sur les réseaux sociaux.

Passage à Debian 12

La version de dev de zds-site contient une mise à jour du paquet Python Pillow qui requiert une version de Python qui demande Debian 12. Le déploiement de la version dev sur le serveur de bêta a donc nécessité de mettre à jour Debian 10 vers la version 12. Les scripts Ansible ont été mis à jour, la mise à jour s’est faite sans difficulté majeure (à part ElasticSearch, mais qui est voué à disparaître).

Le serveur de production et le serveur qui héberge Matomo sont toujours sous Debian 10, leur mise à jour reste à faire. Notamment pour le serveur de production, la mise à jour vers Debian 12 sera nécessaire pour déployer la prochaine version de zds-site (qui n’est pas encore prévue).

Migration du serveur de bêta

Le serveur de bêta a été migré de Scaleway vers PulseHeberg fin octobre, ce qui inclut :

  • les sauvegardes de la production
  • la version bêta du site
  • le système antispam dans les biographies des nouveaux membres

Une documentation a été rédigée et les scripts de déploiement Ansible ont été complétés.

Le serveur Munin de vhf ne supervise pas ce nouveau serveur bêta, l’installation de Munin sur nos propres serveurs est la prochaine tâche à réaliser.

Maintenir Django-Munin ?

On utilise le paquet Python django-munin pour superviser depuis Munin certaines statistiques de zds-site. Seulement ce paquet n’est plus maintenu et le passage à Django 4 demande des changements dans le code du paquet. Aabu a fait une PR sur le paquet et s’est vu proposer de reprendre la maintenance du paquet.

Après avoir considéré les points suivants :

  • la faible quantité de code que compose ce paquet
  • nous sommes le seul projet (apparaissant sur GitHub) à utiliser ce paquet
  • garder un paquet/dépôt indépendant rendrait notre processus plus compliqué (faire une PR sur le dépôt django-munin, publier le paquet pip, faire une PR sur zds-site pour mettre à jour la version du paquet…)
  • la licence du paquet est BSD

Nous avons décidé de ne pas reprendre la maintenance du paquet, mais intégrer le code du paquet directement dans zds-site.

Boîtes mail hébergées chez Gandi

Pour continuer à utiliser nos boîtes mail hébergées actuellement chez Gandi après le 19 novembre, Gandi nous demande de payer (cher).

L’équipe technique décide de migrer les boîtes mails vers Infomaniak. Situphen s’en occupe, une fois que le CA aura donné son accord.

On peut supprimer l’adresse evenement@zds (au pire, ce sera un alias vers association@zds ou communication@zds).

Discussion sur la PR concernant la refonte de la page À propos

Voir la PR en question.

Après discussion, on a besoin des pages suivantes :

  • "L’association" : présentation de l’association (comme décidé lors de la dernière AG) et lien d’adhésion
  • "Technologies" : présentation des technologies utilisées et lien vers la documentation de l’API
  • "Mentions légales" : mentions légales, CGU, cookies, licences

On supprime du pied de page les liens "API", "Cookies" et "Adhérer à l’association".

Concernant la page décrivant les technologies utilisées, on souhaite mettre du détail, puisque ça peut intéresser les visiteurs et visiteuses qui consultent après tout un site de cours (à majorité informatique). Par rapport à ce qui est proposé dans la PR, on ajoute plus de texte, pour expliquer le rôle des différentes technologies, pourquoi on en a besoin. On peut également dire qu’on accueille les développeurs débutant et mettre un lien vers les tickets faciles.

Amaury a besoin d’aide pour ce qu’il y a à mettre dans la page qui présente l’association. Ces éléments peuvent venir du rapport d’activité (dont il faudra mettre le lien sur cette page).

Plusieurs comptes avec la même adresse mail

Cf le sujet correspondant

  • Faire un patch en suggérant d’utiliser de récupérer le mot de passe à l’aide du pseudo.
  • Envoyer un mail à ceux qui ont un compte en double. (une fois le patch déployé en prod et après avoir anticipé comment fusionner deux comptes)
  • Fusionner les comptes dans une migration ? (pas sûr que ça fonctionne aussi facilement….)

Prochaines tâches sur le code zds-site

  • Pas de progrès sur le passage à Typesense, peut-être pendant les vacances de Noël
  • Passage à Django 4
    • travail de préparation avancé
    • encore du travail à faire, notamment certaines vues génériques ont qui changé de fonctionnement et nos vues dérivées doivent être modifiées en conséquence)

La réorganisation des contenus permettra à terme de faire une grosse refactorisation du code des billets/articles/tutoriels.

Prochaine réunion

Début janvier.

+2 -0

On avait prévu de faire une réunion début janvier, voici le sondage pour choisir la date. Je n’ai mis que la deuxième semaine de janvier, n’hésitez pas à dire si vous avez besoin de créneaux la semaine suivante (et ce n’est pas une erreur, je ne suis pas dispo le mardi).

J’ai aussi déjà créé un pad pour le compte-rendu, avec une ébauche de points à aborder, n’hésitez pas à compléter les points dont vous souhaiteriez discuter.

Bonne année ! :)

+2 -0

Voici le compte-rendu de la réunion.

Présents : Aabu, Amaury, k-lipschitzienne (arrivé en cours de route), Situphen et moi-même.

Administration système

Réalisé :

  • migration des mails de Gandi à Infomaniak (merci Situphen !)
  • mise à jour du serveur hébergeant Matomo vers Debian 12 (et PHP 8 en même temps)
  • mise en place de Munin sur notre propre infrastructure : munin.zds et munin.beta.zds avec documentation et déploiement avec Ansible

Prochain gros point : mise à jour du serveur de production vers Debian 12 (nécessaire pour déployer la prochaine version de zds-site)

Héberger d’autres ressources que les images ?

cf le cas du le fichier joint à ce tutoriel

Pertinent, mais attention à ne pas héberger des ressources avec du contenu malveillant. Garder une procédure manuelle ? Puis dans un second temps ajouter une interface ? Dans tous les cas, besoin d’une vérification manuelle (pour la sécurité et la taille).

=> à ajouter au projet de refonte du fonctionnement des galeries ?

Fusionner zds-antispam avec zds-site

Actuellement zds-antispam est dans un dépôt dédié

Permettra de mieux interroger la base de données, et ainsi faire de la détection de spam partout où c’est nécessaire (commentaires, forums, …) et pas que dans les biographies.

Situphen a commencé un travail dans une branche

Plutôt améliorer l’API Rest ?

  • plus simple à intégrer
  • demanderait de beaucoup utiliser l’API et le serveur web, là directement accès à la base de données

Implémentation comme module à part. Avec le mécanisme des signaux Django ? (Qui sont synchrones, vérifier la durée d’exécution pour ne pas alourdir le site !)

Occasion de relancer l’ajout d’un système de tâches (DjangoRQ, Celery, etc.) ? Pas de consensus à ce sujet encore.

Philippe : Se le garder comme (petit) projet étudiant ? Projets étudiants : commencent en septembre, sauf en filière télécoms où c’est un par semestre (donc : projets plus petits)

Pour celui qui le fera : discuter de la solution d’implémentation envisagée avant de foncer tête baissée.

Plans pour 2024

  • passer à Django 4.2 (version actuelle : fin de support en avril)
  • mettre à jour zds-prod à Debian 12
  • une fois que c’est fait, peut-être une version 30.6 de zds-site avec tout ce qui est déjà fusionné (quand même déjà 40 PRs fusionnées !)
  • merger la PR TypeSense et faire ensuite une version 31 de zds-site

Amaury : claps, parcours, (yuzu)

Prochaine réunion

1ère semaine de mars

+3 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte