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 ?
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.
On n’a pas organisé de réunion depuis plusieurs mois et je trouve que cela serait bien d’en organiser une prochainement. J’ai créé ce petit sondage pour que chacun mette ses disponibilités de début décembre.
Prochaine réunion des développeurs de l’équipe technique, lundi 12 décembre à 20 heures dans dans les canaux textuel et vocal « Développement de ZDS » du serveur Discord !
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.
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
PR matomo : typos a corriger et commentaires à mettre ; sera fait à court terme.
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.
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.
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
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.
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.
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).
Déconnecté·eConnecté·e
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.
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.
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é.)
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
