Maintenance du site web de Duniter

HugoTrentesaux · 20 July 2020 12:12

Bonjour à tous, je souhaite vous tenir au courant des choix que j’ai fait pour la réorganisation des sites duniter et monnaie libre et recueillir votre avis pour la suite.

Tout d’abord, j’ai examiné le travail qui avait été fait sur la version française du site duniter. Apparemment, Boris cherchait à appliquer toutes les bonnes pratiques du html et css. Le html était riche en balises sémantiques, le code css était du less compilé, les classes étaient spécifiques… On voit clairement qu’il y a mis beaucoup d’efforts et je comprends son énervement de n’avoir quasiment aucun retour sur son travail.

Malgré toute cette bonne volonté, Boris ne maîtrisait apparemment pas les bonne pratiques d’un générateur de site statique comme pelican, ce qui fait que son code est très difficilement réutilisable dans ce contexte si l’on a des exigences en maintenabilité, et que les articles étaient difficilement accessibles (toute la partie documentation était très difficile d’accès).

Par ailleurs, sûrement à cause du choix d’un police trop petite, Boris a eu tendance à surcharger les zones de texte, ce qui fait que la plupart des paragraphes sont superflus et apportent peu d’information, et avec pas mal d’imprécisions. De plus, l’effet « bloc de texte » en rend la lecture difficile.

Pour toutes ces raisons, le site de Duniter est devenu impossible à maintenir et à mettre à jour, l’information technique était difficile à trouver, et malgré une esthétique plus attirante pour l’œil, le site ne remplissait plus sa fonction première.

Je ne dirai rien sur le site actuel monnaie libre, j’en ai déjà dit assez plus haut, et une lecture attentive de la page d’accueil du site vous donnera une bonne idée du travail à faire. Le site monnaie libre mérite d’être intégralement refait.

J’ai donc réfléchi à la méthode à adopter pour avoir deux sites web :

faciles à maintenir
lisibles
qui ciblent mieux leurs publics respectifs (membres de la ml recherchant des informations techniques ou profils techniques extérieurs pour duniter, nouveaux venus pour monnaie libre, cf plus haut)
un site duniter capable d’accueillir le programme de vulgarisation de la RFC et d’introduire à un éventuel whitepaper
un site monnaie libre donnant vraiment les clés pour rentrer dans le réseau

D’après mon expérience sur la création et la maintenance de sites web, j’ai souhaité partir sur une ré-écriture totale du site et du thème en Zola. Même si cela demande un travail énorme, je suis prêt à la fournir, est c’est une condition non négociable pour que je puisse assurer seul la maintenance de ces deux sites web dans les années à venir tout en accueillant des contributions.

Je prévois le plan de travail suivant :

écrire un thème généraliste assez complet qui me fournisse les éléments dont j’ai besoin pour les sites monnaie libre et duniter
reproduire un version sans régression du site Duniter actuel. Cela signifie un travail de ré-écriture de l’existant, et des scripts de migration du contenu Pelican vers Zola
introduire des améliorations incrémentales comme
- séparation des contenus
- parcours utilisateur
- rédaction de petits textes existants
- optimisation du poids des pages
- système de recherche parmi les articles existants
- documentation du processus de contribution (articles, ressources, corrections, style…)
introduire de nouvelles fonctionnalités comme
- intégration du calendrier d’événements du forum
- intégration d’un wiki géré depuis le forum (ou wiki.js, à voir, cf plus haut)
- multilingue

Cela me prendrait environ :

deux semaines, puis maintenance continue sur la suite
deux mois
une semaine par amélioration incrémentale
à voir, mais pas avant trois mois

J’ai déjà une première version presque sans régression de deux pages du site disponible sur http://duniter.trentesaux.fr/, le code est sur https://git.42l.fr/HugoTrentesaux/zola-duniter pour vous faire une idée. J’ai fait quelques choix esthétiques comme :

largement augmenter la taille de la police pour plus de lisibilité et pour prévoir une réduction des zones de texte
un look « page » plus adapté à un site technique (je réserve le look « pleine largeur » au site grand public monnaie libre)
thème utilisant les couleurs de Duniter pour l’identité visuelle

C’est très Work In Progress, donc pas la peine de me faire des retours sur des détails, ce serait du temps perdu. J’aimerais juste recueillir vos avis sur le plan de travail proposé, afin de ne pas continuer si quelqu’un exprime un veto.

On peut décider à n’importe quel moment de mettre le site en production une fois l’étape « pas de régression » atteinte, mais je pense plutôt à une mise en production tardive vers mars 2021, afin d’avoir le temps de bien lisser l’existant.

vincentux · 20 July 2020 12:31

Il y a du pain sur la planche, mais je trouve super que quelqu’un s’y mette

Oui, celui-ci, il est urgent de le refaire, je ne le partage quasi jamais…

HugoTrentesaux · 20 July 2020 12:35

S’il était beaucoup partagé, ce serait vraiment urgent de le refaire, mais comme il est peu visité, ça relativise l’urgence. Je pense que les gens redirigent plutôt vers le site de leur antenne locale (par ex la toile francilienne ou MLO).

HugoTrentesaux · 20 July 2020 13:49

Un point que je n’ai pas abordé est la conservation des urls existants. Je vais essayer de mettre en place autant de redirections que possible pour minimiser les liens morts. C’est assez facile à faire avec Zola, mais il va falloir que je trouve un moyen d’automatiser ça sinon ce sera ingérable. Autre option, ne rien faire dans Zola directement, mais faire des redirections Nginx permanentes. Pour l’instant je ne sais pas quelle option est préférable.

sveyret · 20 July 2020 14:44

Sacré programme… Félicitations à toi de t’y coller.

J’ai juste 2 questions par rapport à l’avenir : est-ce qu’il sera facile de maintenir ce site à jour (sans devoir passer par les étapes de validation trop lourdes qui font qu’il y a encore des MR vieilles de plus d’un an sur le site actuel) et est-ce qu’il sera facile pour quelqu’un d’autre de reprendre/maintenir tout le travail que tu vas faire ?

HugoTrentesaux · 20 July 2020 14:53

C’est l’objectif, oui.

Quelques indications pour donner confiance dans le fait que ce sera le cas :

Je m’engage à maintenir ce dépôt sur la durée, et de gérer les contributions. Il n’y aura donc plus le problème d’un dépôt sans mainteneur.
Je découple au maximum gestion du contenu / gestion du thème / gestion du style, ce qui permet d’avoir des contributions qui ne concernent qu’une partie des trois (ou une contribution qui les mélange, mais avec séparation en commits).
Je m’engage à documenter en détail les procédures, comme j’ai l’habitude de le faire, de manière à ce que si quelqu’un avait à reprendre le travail à ma suite, il ait les informations pertinentes pour prendre en main le site sans connaître Zola à fond.

Je souhaite justement éviter une n-ième situation où nous serions incapables de gérer les contributions sur un site web qui est au cœur de notre identité en ligne (ma contribution sur le site multilingue n’avait pas pu être acceptée à l’époque).

De plus, je souhaite me servir du site duniter comme support pour vulgariser la RFC en vue d’une ré-écriture et pour faciliter des projets tels que celui-ci.

HugoTrentesaux · 21 July 2020 17:35

Update 1

Les amis, il y a du nouveau. J’ai écrit un script de migration de Pelican vers Zola (https://git.42l.fr/HugoTrentesaux/pelican_to_zola) qui gère pas mal de choses.

Le résultat est que j’ai pu conserver les pages et articles Markdown de l’ancien site à quelques fonctionnalités manquantes près :

table des matières [TOC]
schémas UML
mise en page de certaines images
html intégré à la page

Vous pouvez consulter :

pour vous faire une idée.

Même si ça a l’air bien avancé, ne vous fiez pas aux illusions, il me reste encore beaucoup de travail pour que le site soit réellement exploitable (et surtout documenté). Le script devrait permettre de gérer facilement les changements qui seront faits entre temps sur les articles, je suis basé sur le commit d12f64f2a50cefc1b722f7b3460e14f6e6bdfb3b pour info.

Maaltir · 22 July 2020 09:45

Il y a quelque temps je me disais qu’il faudrait que je me documente sur Pelican, dans le but de participé à la maintenance des sites web.
Aujourd’hui je vois qu’il faudrait plutôt que j’étudie Zola.

Je n’arrive pas à suivre, j’ai plusieurs train de retard.
Ou peut-on trouver des explication sur Zola? Parce mes recherche me renvoie vers un écrivain

tuxmain · 22 July 2020 09:48

https://www.getzola.org/

Maaltir · 22 July 2020 09:50

Merci!
Je vois que c’est encore en anglais! Je crois que je vais laisser faire les pros…

HugoTrentesaux · 22 July 2020 15:38

@Maaltir comme promis, je vais écrire (en français) une documentation spéciale pour contribuer sur le futur site web de Duniter. Je veux bien t’accompagner dans ton apprentissage, j’ai déjà écrit un « quickstart » pour Zola en anglais et en français ( ). Si tu as des questions, tu peux également les poser sur le forum de Zola. L’auteur de ce logiciel est français (de Nice), donc pas de problème pour parler français.

Maaltir · 22 July 2020 18:16

Ok je vais regarder çà!
Mais je vois bien que j’ai beaucoup de wagon à rattraper… Gros boulot pour moi.

HugoTrentesaux · 23 July 2020 21:18

Si tu veux qu’on se fasse une petite séance de formation en partage d’écran, c’est possible quand tu veux mais si tu veux juste contribuer au site et pas forcément apprendre Zola, il vaut mieux attendre que je documente l’ensemble.

ManUtopiK · 23 July 2020 22:02

Super initiative la refonte du site !

Curieux que zola utilise +++ pour frontmatter au lieu de --- comme la plupart des SSGs markdown…
Dommage de ne pas utiliser un moteur de site statique en javascript. Je ne comprend pas l’intérêt vu que les navigateurs sont en js. C’est quand même top de pouvoir intégrer des composants js dans du markdown et du markdown dans du js !

Sinon, il serait peut-être aussi pas mal de sortir les fichiers .md du contenu du site ?
Au lieu d’avoir le contenu dans le dépôt du générateur de site ici : https://git.duniter.org/websites/website_fr/-/tree/master/content
Ce serait mieux d’avoir un dépôt dédié au contenu, et un autre dédié à la génération du site. C’est SoC (Separation of Concern). D’un côté le text du site : la data, et de l’autre le générateur : le code. Ce sera mieux pour les contributeurs non techos, et pour les devs afin de générer le site avec différents moteurs de SSG (ça évolue vite tout ça…).
Ce sera aussi plus simple pour plugger wiki.js si il y a besoin. J’ai testé wiki.js seulement, jamais utilisé en prod. Je ne me sens pas d’installer ça de suite, et c’est peut-être un peu prématuré ?

Par contre, je peux installer un nuxtjs avec PWA (mobile et offline) et nuxt content en 2-2
Je me dis que ce serait même génial pour merger le contenu du site en markdown avec un moteur de recherche de liens comme veut le faire infojune.fr
Avec nuxt content, tu lui donnes un json avec des liens structurés par exemple, et il fournit une API. Pratique pour faire un moteur de recherche ou des listes…

HugoTrentesaux · 23 July 2020 23:46

Merci

La plupart des navigateurs peuvent interpréter du javascript, mais :

certaines personnes désactivent le javascript en utilisant des extensions comme noscript pour des raisons de sécurité
le javascript a un coup à l’exécution qui peut devenir important pour les machines les plus modestes (pense à mon vieux smartphone qui a plus de cinq ans et qui sue quand il s’agit de faire tourner du js)
les robots ne lisent pas le javascript, c’est donc mauvais pour l’indexation du contenu. Pour un site censé faire référence, ça la fout mal.
personnellement, je n’aime pas le javascript. Je sais l’utiliser quand j’en ai besoin (exemple : Brain viewer) mais moins j’y touche, mieux je me porte. D’ailleurs je haïs npm et node.
pourquoi faire travailler le client pour faire des calculs qu’on peut faire en amont ? niveau consommation énergétique c’est beaucoup moins bien (pense à l’autonomie de nos vieux smartphones encore une fois).
certains navigateurs n’interprètent pas le javascript. Perso j’utilise assez souvent lynx, et ça me fait chier quand je tombe sur un site qui ne fonctionne pas sans js
l’usage de javascript encourage les gens à utiliser chrome / chromium parce que son moteur de javascript est nettement plus performant que celui de firefox. D’accord c’est un peu subtil, mais je ne souhaite pas participer à ça
si j’ai vraiment besoin de js à un endroit dans le site, je peux quand même l’utiliser

Comme tu vois, aucune réponse n’est un argument marteau, mais c’est une somme qui me fait préférer d’éviter ça.

C’est “mieux” théoriquement d’un point de vue bonnes pratiques, mais en vrai, c’est sacrément chiant. Tout simplement parce que le contenu et sa mise en forme sont assez intriqués, on a souvent besoin de changer les deux en même temps, et ça fait deux fois plus de commits à faire, trois si on compte le thème. C’est pourquoi après beaucoup d’expérience dans ce domaine, je préfère de loin avoir le thème, le contenu, et la config du site au même endroit.

Non, au contraire, ça le perd encore plus.

C’est faux aussi. Même si le contenu est écrit en markdown dans tous les cas, la façon de l’organiser, les métadonnées, la manière de lier les fichier statiques, les shortcodes spécifiques au SSG rendent la migration fastidieuse. Ce n’est pas pour rien que je travaille sur un script de migration, si c’était aussi simple que de drag and drop d’un dossier à l’autre, tu te doutes bien que je ne m’embêterais pas à écrire un script pour ça.

Ça reste à prouver. Fais les deux et reviens me voir après.

Ça dépend. Si on le pense comme un projet indépendant, ça peut arriver n’importe quand. Si on veut l’intégrer au site, il vaut mieux attendre un peu, oui.

Oui, comme toujours on peut faire un tas de choses, ce qu’il faut, c’est savoir pourquoi telle chose est pertinente ou non et si on aura les ressources humaines pour le maintenir à long terme. Oui, il y a plein d’outils pour faire des tas de trucs et ils sont tous mieux conçus et plus astucieux les uns que les autres, mais non, on n’a pas envie de diversifier excessivement parce qu’après c’est ingérable. Donc avant de proposer le prochain trucjs à la mode qui s’installe en un clin d’œil, essaye de répondre aux questions suivantes :

es-tu prêt à assurer seul sa mise en place et sa maintenance à long terme
es-tu prêt à écrire une documentation suffisante pour que n’importe qui puisse utiliser l’outil sans avoir à apprendre à s’en servir

Je veux bien faire un rappel sur les points qui ont guidé mon choix de techno :

j’ai une grande expérience sur Zola et c’est un outil avec lequel je me sens à l’aise, suffisamment pour avoir envie de travailler avec pendant les trois prochaines années au moins
c’est un outil “low tech” il demande très peu de ressources et est extrêmement rapide
il inclut la compilation sass nativement ce qui simplifie grandement l’écriture de style
il est doté de toutes les fonctionnalités dont j’ai besoin et les remplit bien. Pas besoin d’installer de plugin
il fait partie de l’écosystème Rust auquel je souhaite contribuer
je suis prêt à aider des gens (comme @Maaltir) pour apprendre à s’en servir

Après ce très long message, j’aimerais ne plus avoir à parler de choix technologique sur ce sujet. Je préfère me concentrer sur la refonte du site (qui a avancé, je vais écrire un prochain message).

HugoTrentesaux · 24 July 2020 00:13

Update 2

Bonjour les amis, voici le temps du deuxième update. J’ai quelques questions à vous poser :

@cgeek, @vit, @elois, vous avez écrit des schémas en utilisant le plugin UML. J’ai conservé le code et les images compilées mais Zola ne compile pas l’uml. Aurez-vous besoin à l’avenir d’un outil intégré pour compiler les uml, ou pouvez-vous vous contenter d’un outil externe ?
je trouve que la page monnaie libre n’est pas extrêmement pertinente est-ce nécessaire que je la reproduise à l’identique, ou une version sans mise en page est-elle suffisante ?
j’ai atteint une certaine stabilisation pour la migration mais j’ai besoin de savoir si vous voyez des problèmes dans les pages afin de pouvoir passer à la suite. Ça m’aiderait que vous parcouriez rapidement le site afin de voir s’il y a des bugs que je n’aurais pas vu (mauvaise mise en page d’images, lien cassés…)
jugez-vous essentielle la fonctionnalité breadcrumb ? si oui, je peux la coder dans mon thème, ce n’est pas un problème, mais si non, je pense m’en passer. Je ne la trouve pas indispensable et ça me ferait gagner un peu de temps.

Par rapport aux tables des matières, j’en ai inséré une systématiquement dans chaque page et ai laissé les balises [TOC]. C’est donc normal si elles se baladent dans la nature. J’attends de voir si j’ai suffisamment bien effectué la migration pour pouvoir me détacher du contenu original et retravailler le contenu du site lui même sans avoir à régler des conflits de migration.

Prochaine étape :

gestion convenable des auteurs / tags / catégories
légère optimisation SEO pour que les robots sachent bien décrire les pages
abstraction des améliorations pour enrichir le thème qui servira aussi pour le site monnaie libre (avec un autre design, bien sûr)
[bonus] flux rss / atom

Étape d’après :

la documentation promise
polissage du contenu
- refaire les pages de section
- relire les textes de présentation
- ré-organiser le contenu
polissage du thème
- amélioration des listings automatiques (pages / sections)
- meilleur positionnement pour la TOC

Étapes ultérieures à la mise en service (nouvelles fonctionnalités) :

intégration d’un wiki (wiki discourse, wikijs ?)
intégration automatique d’information externes (licence, numéro de version logiciel, documentation développeur…)
intégration d’un calendrier discourse
multilingue
chantier de vulgarisation de la RFC

elois · 24 July 2020 00:26

J’en ai fait très peu moi-même, donc ça ne me dérange pas de les refaire avec un outil externe, par contre je ne pense pas que @cgeek aura le temps de refaire tous ses schémas, et je ne me sens pas de le faire a sa place, donc on va perdre des schémas, a voir quels sont les plus importants à garder, et lesquels on peut se permettre de perdre.

Perso je la trouve pertinente sur le fonds, après sur la forme ça m’est égal, donc ok pour une version sans mise en page

Je ne suis pas sûr d’avoir compris ce que l’on doit vérifier, quand je http://duniter.trentesaux.fr/ la plupart des liens pointent sur la page courante avec un # en plus donc ils sont presque tous cassés ou juste pas migrés ? Quand a la mauvaise mise en page je suis nul pour repérer ce genre de truc

Je trouve que c’est un plus qui aide beaucoup a la navigation. C’est une fonctionnalité que j’apprécie beaucoup lorsque je navigue sur un nouveau site. Ce n’est bien entendu pas indispensable, mais je trouverai dommage de perdre ça.

tuxmain · 24 July 2020 06:12

Avec le validateur, on voit quelques problèmes pouvant causer des bugs de mise en page pour certains navigateurs (surtout des attributs width avec unités, qui devraient être remplacés par du CSS, mais bizarrement Firefox supporte ça).

Edit: quelques problèmes d’accessibilité et référencement aussi

ManUtopiK · 24 July 2020 09:31

Oulà, je disais juste ça à titre de conseil…

Loin de moi vouloir troller, mais la somme est nulle, pas un de tes arguments n’est juste :
Va sur la doc de silkaj réalisé avec vuepress, désactive le javascript : le site est le même !
Juste la navigation n’utilise pas l’api html5 pour le routage, mais ça recharge la page au lieu de naviguer directe ; régression transparente.
62.8 KB de js, ça va ton vieux téléphone et firefox peuvent tenir le coup… (ce forum utilise 4.2MB de js).
Toutes les balises meta et le sitemap sont construit au compile time, c’est SEO friendly. C’est pas le client qui travaille, c’est ton ordi lors de la compilation. Tous les calculs sont justement fait en amont, même pas de serveur, c’est quand même mieux en conso énergétique. Mais bon, zola fait ça aussi. Je pense qu’il y a une incompréhension sur ce que fait réellement le javascript… un SSG javascript peux comprendre le javascript dans un fichier markdown au compile time, charger les composants dont à besoin la page et les intégrer directement pour le runtime. Zola, Hugo, Pelican, Jekyll… et autres SSG non js ne peuvent pas faire ça.
Avec nuxt, tu peux commencer le site en statique, puis passer en PWA ou en SSR en changeant juste un paramètre. C’est fait pour évoluer en fonction des besoins et la taille du site…

Benchmark :
http://duniter.trentesaux.fr ← 18 requests, 7 fichiers css, 1.2MB

https://mystifying-nobel-66ae54.netlify.app/fr/ ← 17 requests, 1 fichier css, 588 KB

Et encore, les perfs sont plombées par la taille des images… Bon ok, ce site fait en 2020 à du javascript, ça craint. Par contre tu l’installes sur ton smartphone comme une appli web, et tu navigues hors ligne… Perso je préfère plutôt désactiver le wifi que javascript, mais là tu peux même faire les 2
Côté allergique à js, tu fais yarn dev au lieu de zola build dans ton bash et tu créés le site en live sans recharger le site, il te suffit juste d’oublier que c’est du js en fait…

Côté séparation contenu, c’est justement pour éviter ce genre de problème. Chacun pourra compiler le site avec le moteur SSG de son choix…
Si le contenu est couplé avec la mise en forme, c’est qu’il y a un problème SoC (Separation of Concern) avec ton SSG. Pour les nons techos, c’est quand même plus clair de ne pas avoir d’autres fichiers que les fichiers du contenu en .md. En terme de gestion du site, ils n’ont pas à ce soucier d’avoir des commits et issues sur le code au milieu d’issues et commits sur le contenu… c’est pas pour rien que tous les gros outils open source font comme ça pour leurs docs ! Il n’y a qu’à parcourir github…
Enfin, tu peux avoir un fichier markdown que n’importe quel rédacteur à l’aise en markdown peut comprendre :

<breadcrumb />
<toc />
# Bienvenue !
La **june** compte actuellement **<g1-members-count /> membres**.
Le dividende est de <g1-dividend />.

Les composants mettent à jour automatiquement listes et compteurs. Pas une ligne de js. Et tu peux compiler ça pour du vuejs, react, svelte… peu importe ! Pas besoin de scripts de migration et autres shortcodes… c’est juste du html + md. Pas besoin de templates et autres {% extends %} séparant le contenu de la vue…
Pour les devs se sera aussi plus simple.

Tout ça n’est pas que le dernier trucjs à la mode. Tu as déjà utilisé gatsby, vuepress ou du headless cms comme strapi ? Moi oui et depuis longtemps, et je comprend tout l’écosystème que c’est mis en place autour des SSG, headless ou JAMstack…
Les points qui guident mes conseils sont aussi une grande expérience, des outils low tech et rapide (vitejs avec vue3, c’est de l’import de module en natif. Ça peut pas être plus rapide, c’est natif !). De la compilation sass, less, postcss… depuis le composant direct (encore SoC), avec assurément plus de fonctionnalités (RSS, breadcrumb et import uml et surtout du PWA !) et utilise un language à la base fait pour le web et pas pour les serveurs.
En terme de maintenance pour les 3 prochaines années, ce sera sûrement plus simple à gérer et évolutif qu’un outil qui ne respecte pas les standards front matter, fait pas d’i18n et n’utilise pas les dernières avancées du web (build modulaire js et css, HMR, PWA, import js natif…).

Maintenant, je dis tout ça juste à titre de conseil justement pour expliquer pourquoi telle chose est pertinente ou non… Mais j’ai l’impression de rentrer dans une gueguerre de specs techniques que je ne pensais pas générer avec mon précédent post…

Bref, j’émettais seulement des idées et proposais d’installer tout ça avec nuxt. Vu la réaction, je sais plus… Je le ferais plutôt plus pour monnaie-libre, et assurer la construction et maintenance du générateur, pas forcément du contenu.
Pour la mise en place j’ai pas la main, @moul doit faire une CI avec gitlab pour la doc Silkaj pour que ce soit sur “nos” serveurs. En attendant, l’hébergement gratos installé en 5 min sur netlify marche toujours très bien depuis des mois…

Tout ça à définitivement à voir avec le 1er post de ce topic : boucles de rétroaction trop longues, processus conflictogène… Chacun fait à sa sauce sans concertation et avec ses convictions… et c’est toujours aussi difficile de savoir qu’est-ce qu’il y a à faire et qui fait quoi dans le process de cette ML…
Pour pouvoir fonctionner en réseau, il faut de la transparence.

Bref, j’adhère à 100% aux remarques de @anon88550267 !

HugoTrentesaux · 24 July 2020 11:13

Oups, je me suis mal exprimé. Les schémas actuels sont conservés en tant qu’images, et le code est là aussi. C’est juste que si on veut les modifier, il faudra les recompiler avec un outil externe car Zola ne gère pas la compilation des uml. Donc aucune perte de schéma, mais modification de ces schémas moins immédiate qu’avant.

Zut, je me suis encore mal exprimé. Quand je parlais de migration, il s’agissait de tous les articles et de toutes les pages du wiki (actualités/wiki). Les pages “custom” (accueil/logiciels/g1/monnaie-libre) sont encore brutes et seront retravaillées au moment du polissage.

D’accord, c’est donc parti pour ajouter un breadcrumb au thème.

Merci pour le signalement. Pour l’instant on est sur du brut, j’utiliserai le validateur au moment du polissage pour régler ces erreurs. Pareil pour l’accessibilité, encore que je n’ai aucune compétence là dedans.

Bah c’est justement ça que j’ai mal pris je n’aime pas tellement qu’on me conseille un outil en disant :

alors que mon choix est mûrement réfléchi. Ça ne m’aide pas, c’est juste gênant, et ça me freine dans le travail que je suis en train de faire.

En effet, je me suis emporté, je n’ai pas compris comment fonctionnait cet outil.

C’est ça que je n’avais pas compris. Je pensais que le markdown était rendu chez le client via du js dans son navigateur. Je crois que c’est ta remarque :

qui m’a induit en erreur.

oui, ça me gène beaucoup

Bah si, il faut bien un serveur pour servir des fichiers statiques !

Merci pour les Benchmarks, est-ce que tu pourras m’aider à optimiser le site en temps voulu ? Pour l’instant l’objectif est juste de migrer le contenu du site depuis Pelican.

Je suis aussi allergique à yarn

je sais que c’est pas très rationnel, mais je suis un peu js-phobe

J’ai envie de te dire “fais le”. Si c’est si facile avec tes outils, fais-le avec tes outils, mais ne viens pas ~~me faire chier pour~~ me demander de faire autrement que la manière dont je suis en train de faire. Au cas où tu n’as pas compris, cette discussion m’énerve.

Tant mieux pour toi, je fais avec mes outils, je le fais et je suis content. Je sais comme c’est tentant de partager des outils dont on est fan, mais ici n’est vraiment pas l’endroit pour ça. Ici est un sujet sur le forum duniter pour refondre le site duniter, pas une plateforme de promotion pour des outils, js ou pas. Si tu veux m’aider, aide moi, si tu veux faire la course, fais le travail dans ton coin et ponds une version du site avec tes outils, et propose-la (si ça se trouve, ce sera mieux et ça m’évitera de passer des heures sur ce site).

Le problème de la maintenance n’est pas tellement un problème d’outil, c’est un problème humain. Il faut un bonhomme qui soit là pendant les trois prochaines années pour maintenir le site, c’est tout. Si tu veux être ce bonhomme, annonce-le, mais si non, alors laisse moi utiliser les outils que je veux, sachant que, je le répète :

Bah voilà, même si tu as raison sur les specs, j’ai perçu tes conseils comme une leçon de morale, et ça m’a énervé.

Excellente idée ! On n’a qu’à dire que je travaille sur le site duniter, tu travailles sur le site monnaie libre, et comme ça on peut s’aider mutuellement sans se gêner. Est-ce que tu peux ouvrir un autre post pour en parler ? Là j’aimerais surtout parler du site de duniter.

Et moul semble un peu débordé parce que depuis qu’on s’est vu au ground control et que tu avais entrepris de faire ce site, il n’est pas encore passé en prod.

En effet, c’est tout à fait dans le sujet. Mais là, voilà comment j’ai vu les choses :

je me propose pour reprendre la responsabilité du site duniter après l’avoir migré en Zola
je tiens les gens au courant de l’avancée
tu arrives en me disant de faire autrement

Tu peux comprendre qu’avec cette vision je sois un peu énervé.
J’imagine que ta vision est la suivante :

il y a un problème de maintenance des sites
je propose de faire à ma façon
tu me conseilles des outils plus adaptés pour ce que je veux faire
je réponds de manière désagréable

Donc je comprends aussi ton doute :

Mais je pense que ce serait dommage que nos volontés se neutralisent, la meilleure option me semble être celle que tu proposes :

Si on fait comme ça, non seulement ça me décharge de la responsabilité du site monnaie libre qui me faisait un peu peur (je préfère me concentrer sur le site duniter) mais en plus, on a officiellement une personne pour maintenir ce site dont pour l’instant personne ne s’occupe.

Je ne sais pas à quelles remarques tu fais référence, mais j’espère que ma réaction ne va pas te faire “ragequit” comme lui. Si tu veux bien, on fait la paix et on travaille chacun sur notre site

fini la

et c’est parti pour

!