Organisation des forks

[TFCx]

Hello.

On s'approche d'une V1 pour Montpellier... (oui je sais, je dis ça tous les mois). Version actuelle disponible ici https://observatoire-velo-montpellier.netlify.app.

A force de travailler sur mon fork, je me pose la question de l'organisation. En effet, j'ai l'impression qu'il peut y avoir des fonctionnalités propres à chaque ville... Par exemple, je ne visualise les lignes pas tout à fait comme sur Cyclopolis ; j'ai besoin de gérer des réseaux en arbres ; d'afficher une notion de qualité perçue, etc. Certains de ces modifications pourraient bénéficier aux autres projets... Ou au contraire être inutiles pour eux.

A côté de ça, nous avons évidemment des données GIS propres, mais aussi un habillage graphique légèrement différent. Et je ne parle même pas de la base de code qu'on pourrait souhaiter faire évoluer techniquement (j'ai vu que Marseille tentait d'utiliser Pinia qui pourrait me tenter aussi pour gérer les stores vuejs).

Comment concilier ça avec le projet Github originel ? Est-ce qu'il faut à tout prix maintenir un projet GH unique ? A ce moment là, ça impliquerait que les différentes villes qui veulent une version doivent avoir des branches release/nomdemaville par exemple. Et que dans le tronc de base, il n'y ait pas de données de Lyon... Pas forcément très pratique.

Ou à l'inverse, admettre qu'il existe une collection de forks (comme actuellement) et que chaque projet doit rester "au courant" des évolutions des autres projets pour récupérer ce qui peut l'être (si besoin).

Ca rejoint un autre point de complications : la communication entre devs et entre projets. @benoitdemaegdt me proposait de continuer à passer majoritairement par les issues du projet... Mais bon, avoir un projet "particulier" (avec des données particulières) où discuter potentiellement de fonctionnalité d'une autre ville... c'est pas tip-top. J'avais proposé de plutôt centraliser les discussions sur la Mattermost de la FUB qui me semble + adapté pour ça. En tout cas, c'est très lié au fait d'avoir un projet GH ou plusieurs projets GH.

Enfin, dernière question : quid du nom Cyclopolis... Est-ce que LVV souhaite que ce nom soit plutôt commun et réutilisable pour tous les projets ? Et donc qu'il y ait des Cyclopolis Lyon, Cyclopolis Montpellier, etc. Ou que Cyclopolis ne soit la marque de l'observatoire vélo que de Lyon ? (poke @ThibautChd @Delapouite)

[benoitdemaegdt]

Hello @TFCx 👋

Merci pour cette issue, c'est un sujet important 👍

On s'approche d'une V1 pour Montpellier... (oui je sais, je dis ça tous les mois). Version actuelle disponible ici https://observatoire-velo-montpellier.netlify.app/.

Super classe, j'adore les différentes visualisations (qualité, type, avancement) 👏

A force de travailler sur mon fork, je me pose la question de l'organisation. En effet, j'ai l'impression qu'il peut y avoir des fonctionnalités propres à chaque ville... Par exemple, je ne visualise les lignes pas tout à fait comme sur Cyclopolis ; j'ai besoin de gérer des réseaux en arbres ; d'afficher une notion de qualité perçue, etc. Certains de ces modifications pourraient bénéficier aux autres projets... Ou au contraire être inutiles pour eux.

A côté de ça, nous avons évidemment des données GIS propres, mais aussi un habillage graphique légèrement différent. Et je ne parle même pas de la base de code qu'on pourrait souhaiter faire évoluer techniquement (j'ai vu que Marseille tentait d'utiliser Pinia qui pourrait me tenter aussi pour gérer les stores vuejs).

Comment concilier ça avec le projet Github originel ? Est-ce qu'il faut à tout prix maintenir un projet GH unique ? A ce moment là, ça impliquerait que les différentes villes qui veulent une version doivent avoir des branches release/nomdemaville par exemple. Et que dans le tronc de base, il n'y ait pas de données de Lyon... Pas forcément très pratique.

Ou à l'inverse, admettre qu'il existe une collection de forks (comme actuellement) et que chaque projet doit rester "au courant" des évolutions des autres projets pour récupérer ce qui peut l'être (si besoin).

Pas hyper évident comme sujet haha 😅
Pour moi, l'idéal serait d'avoir une base de code commune qui regrouperait les fonctionnalités core : carto, une page par ligne etc ...
Chaque asso irait alors piocher la dedans, et pourrait ajouter des "plugins" ou "entensions" pour ses fonctionnalités propre.

Une fois qu'on a posé ça, on se rend vite compte que c'est un boulot énorme, et qu'il faudrait presque un temps plein pour faire la conception et la maintenance d'un tel système.
Donc pour moi, on va naturellement (c'est déjà le cas), se diriger vers des forks qui vont dévier et vivront leur propre vie.
ça me semble ok, puisque comme tu dis il y a plein de spécificités locales.

Ca rejoint un autre point de complications : la communication entre devs et entre projets. @benoitdemaegdt me proposait de continuer à passer majoritairement par les issues du projet... Mais bon, avoir un projet "particulier" (avec des données particulières) où discuter potentiellement de fonctionnalité d'une autre ville... c'est pas tip-top. J'avais proposé de plutôt centraliser les discussions sur la Mattermost de la FUB qui me semble + adapté pour ça. En tout cas, c'est très lié au fait d'avoir un projet GH ou plusieurs projets GH.

Allez, je commence à être convaincu par le MM de la FUB 😄
On a un contact la bas pour avoir un avis ? cc @ThibautChd

Enfin, dernière question : quid du nom Cyclopolis... Est-ce que LVV souhaite que ce nom soit plutôt commun et réutilisable pour tous les projets ? Et donc qu'il y ait des Cyclopolis Lyon, Cyclopolis Montpellier, etc. Ou que Cyclopolis ne soit la marque de l'observatoire vélo que de Lyon ? (poke @ThibautChd @Delapouite)

je n'ai pas d'avis sur la question. C'est le nom que j'ai donné au projet parce que le nom de domaine était dispo et que je trouvais ça classe, mais il n'y a pas eu de réflexion plus poussée 😄
@ThibautChd , un avis sur la question ?

[ThibautChd]

Salut Benoit et Jean-David,

Jean-David soulève effectivement des questions qui vont devenir essentielles avec le déploiement de toutes une série de forks qui vont nécessairement s'éloigner de notre Cyclopolis lyonnais. Vu les temps bénévoles que nous passons sur ces projets, je rejoins Benoit sur le fait qu'il est illusoire de modifier le projet Cyclopolis pour faire un beau tronc commun non territorialisé. Le mieux est donc que chacun fasse avancer son fork comme bon lui semble pour l'adapter à son territoire. En revanche, pour ne pas que les bonnes idées des uns et des autres se perdent ou restent dans une ville, je pense que l'idée du Mattermost est intéressante. Elle permettra de créer du lien au fil de l'eau entre les projets. En plus de cela, je propose de réunir la "communauté Cyclopolis" deux fois par an pour un "comité de partage" de 2h un soir dans la semaine où chaque groupe présenterait quelques évolutions spécifiques qu'ils ont développé sur leur territoire, pour inspirer les autres ou tout simplement les informer que cela existe. Tout cela dans une optique d'émulation de manière à ce que les idées des uns puissent servir aux autres. Qu'en pensez-vous ? Ca me dit bien d'animer ce comité avec la FUB si c'est une idée qui vous convient.

Concernant le nom, Cyclopolis n'est pas une marque destinée à parler uniquement de l'agglo lyonnaise. Si d'autres agglo veulent appeler leur plateforme "Cyclopolis Poitiers", je n'y vois pas d'inconvénient tant qu'on fait bien le distinguo avec la version lyonnaise ! :)

[TFCx]

Assez d'accord avec vous : actuellement, ça me parait irréaliste de faire un cœur réutilisable et maintenable pour tout le monde. On le voit même avec les autres projets en cours (Marseille, Bordeaux, ...) : il y a souvent au + un mainteneur, et qui a des grosses périodes d'inactivité.

Donc dans un premier temps, je dirai aussi : des forks avec le risque de diverger (ou au moins être en retard question fonctionnalités). Du coup, avec cette option, je pousserai pour regrouper par contre les canaux de discussion au niveau de la FUB (donc du MM ?).

Faire un petit groupe de travail qui se réunit 1/2 fois par an peut effectivement être cool. En tout cas, je crois bcp à l'outil (et à des évolutions) donc je pense que je vais continuer à y investir du temps (même si je suis papa depuis une semaine... ce qui a fait disparaître tout mon temps libre :p)

Pour le nom, c'est à double tranchant. Ça permet certainement de donner une marque forte et du poids tout de suite à un projet associatif. Et ça poussera les villes à "se comparer" dans les objectifs. Inconvénient, le nom est peut être un peu complexe. On nous a fait remarqué qu'il y avait le son "police" également dedans (je ne sais qu'en penser). Ca demenderait aussi à ce que le nom de domaine cyclopolis.fr soit un portail général avec des liens vers tous les forks. Et que les sous-projets s'appellent "Cyclopolis Lyon / Montpellier" etc.

Peut être rajouté un sous-titre "Cyclopolis - L'observatoire vélo de XXX" ?

Oui d'ailleurs, ça rejoint une autre question : quel est le but du développement de Cyclopolis Lyon ? Pour Montpellier, on a délimité probablement que c'est un outil de plaidoyer pour s'adresser au grand publique comme aux politiques et pour objectiver les transformations (ou les manques) qui touchent au développement du vélo dans la vile. Mais que ça ne serait PAS un outil d'aide aux cyclistes (en gros, on cherche pas à concurrencer Geovelo par exemple) / aux trajets. D'où le fait qu'on est vraiment un observatoire.

[ThibautChd]

Je pense qu'on converge maintenant pour regrouper les échanges interassos sur Cyclopolis au niveau de la FUB sur MM. Ca va être l'occasion pour moi de me mettre à MM^^ Jean-David ce serait dans tes cordes de créer un fil dédié à ces échanges sous MM ?

De mon côté, je vais me rapprocher de la FUB pour organiser un premier rendez-vous d'échanges techniques sur les plates-forme de suivi REV au premier semestre 2025. Je vous tiendrai au courant !

Pour le nom, je pense que chaque asso peut garder une liberté totale. Cyclopolis est devenue une marque bien ancrée et reconnue chez nous. Et ce sera compliqué de changer le nom de domaine, car Benoit a investit beaucoup d'énergie pour que Cyclopolis soit parfaitement référencé dans les moteurs de recherche. Ca a très bien marché, mais ça implique que cyclopolis.fr reste dédié à la version lyonnaise, sauf à refaire tout ce boulot de référencement. Ton idée de portail général est top, mais arrive je pense trop tard. Peut-être que @benoitdemaegdt le voit différemment. Ca implique que chaque asso peut garder ou non le titre Cyclopolis, où préfère changer de nom. Je pense de toute manière que l'important c'est le contenu du site, et pas son nom. Et à partir du moment où on aura une page qui regroupe les liens vers tous les fork des observatoires vélo, il n'y aura pas de soucis.

Concernant le but du développement de Cyclopolis Lyon, il est complètement en phase avec le votre. Il est destiné au grand public et aux politiques. Pour donner un peu de vision sur notre backlog, après avoir finalisé la partie suivi des Voies Lyonnaises, on est en train de s'attaquer à la partie Compteurs où on comparera notamment trafic vélo et voitures. En parallèle, on va développer une "carte des services" qui regroupe tous les lieux où on retrouve du service pour les cyclistes (stationnements, ateliers, véloécoles, revendeurs, etc). Enfin, à partir de l'été 2025, on devrait créer une partie dédiée aux élections municipales où on pourra cartographier nos besoins en aménagements cyclables sécurisés supplémentaires notamment.

PS : Félicitations au jeune papa ! :)

[TFCx]

D'accord avec ce que tu dis :)

J'ai crée un thread dans MM que je t'ai envoyé. J'espère même avoir un canal de discussion complet (ça permettra d'échanger sur d'autres points).

Donc on part également sur une page "partenaires" (ou autre nom à décider) qui référencent d'autres observatoires. Mais chaque site fait ce qu'il veut. Et on vous laisse la marque Cyclopolis (propre à Lyon). On partira probablement vers Observatoire du plan Vélo Montpellier.

Je laisse l'issue ouverte pour l'instant, si il y a d'autres contributions.

[XioNoX]

Vu que cet outil à aussi vocation de devenir une plateforme de plaidoyer pour les élections (et c'est super!, j'ai hate!) je me demande si il y la possibilité d'avoir un "entre-deux". C'est à dire qu'une asso avec des connaissances limités en développement puissent maintenir un fork sans trop le voir diverger avec la version "vanilla".
Le risque étant que plus le temps avance, moins les différentes assos puissent profiter des avancées de tout le monde.
Par exemple déplacer versconfig.json plus de variables. (comme ce que j'ai "hardcodé" dans 895d2e4, 752aa5f, bea8b8b, la distance totale, le cout (si défini, etc), la couleur du "thème"). En gros avoir le moins de fichiers possible à modifier à partir d'une installation "de zéro".
Puis idéalement que les fonctionnalités qui peuvent être utiles au plus grand nombre soient "bakportées" dans le tronc commun, je pense par exemple à la gestion de la "qualité" d'un tronçon fait par Montpellier qui semble top.

[paulop33]

Hello,

Je rejoins totalement @XioNoX.
Il me semble assez évident que Lyon est la seule agglo de France où la qualité n'est pas à redire lors du déploiement du réseau vélo.
Je viens de créer une PR incomplète qui reprend cette notion de qualité sans l'imposer.
Ainsi, la qualité peut être affichée sur le tooltip de la carte et via un composant pour le texte.

Par défaut, cette fonctionnalité est désactivée et il suffit de passer le boolean displayQuality du config.json à true pour commencer à afficher des choses.
Pour plus de détails, je vous recommande la PR : #468

J'espère que cela fera avancer le débat

[TFCx]

Pour info, je suis en train de synchroniser le fork de Montpellier avec le master de Lyon. Du coup, je merge progressivement, commit à commit, les nouveautés du fork de Lyon. C'est un peu fastidieux, mais c'est faisable (et forcément, ça serait plus simple si je l'avais fais au cours des 6 derniers mois 😅).

Une fois complètement synchronisé, je devrai pouvoir faire un diff et regrouper les modifications entre ce qu'on veut garder de propre à Montpellier (l'affichage) et ce qui peut être mutualisé (j'avais repéré des bugs qui ont depuis été corrigés :) ).

Le + on peut mettre en commun, et proprement dans le config.json, le mieux ça sera :)

[ThibautChd]

Il ne faut pas croire, à Lyon aussi il y aura des tronçons pas top, issus majoritairement d'existant médiocre qui ne sera pas amélioré à court-terme. On a donc aussi dans les tuyaux de gérer la qualité, mais ni comme @paulop33 avec ses 6 niveaux, ni comme @TFCx avec ses 4 niveaux, mais de manière plus binaire avec 3 niveaux (OK, NOK, inconnu). Tout est détaillé ici : #406 (comment)

C'est là qu'on voit qu'en fonction des sensibilités de chacun sur la qualité, la feature "quality" va vite diverger d'une agglo à une autre et qu'il sera difficile de faire un composant standard qu'il suffirait d'afficher ou masquer au besoin.

[benoitdemaegdt]

Hello @TFCx 👋

Pour info, je suis en train de synchroniser le fork de Montpellier avec le master de Lyon. Du coup, je merge progressivement, commit à commit, les nouveautés du fork de Lyon. C'est un peu fastidieux, mais c'est faisable (et forcément, ça serait plus simple si je l'avais fais au cours des 6 derniers mois 😅).

Oui en effet, ça s'annonce fastidieux 😓
Je vais faire en sorte que ce soit plus facile, en ne faisant qu'un commit par nouvelle fonctionnalité. Ainsi tu pourras "cherry pick" uniquement les fonctionnalités qui t'intéressent. Ce sera plus facile que d'avoir des dizaines de commit en vrac dans l'historique, pas forcement liés entre eux.

Le + on peut mettre en commun, et proprement dans le config.json, le mieux ça sera :)

ça me va bien de pouvoir activer / désactiver une fonctionnalité depuis le config.json.
Partons là dessus 👍

[XioNoX]

Aussi mettre la couleur dominante du site dans le config.json serait utile (XioNoX@772bdfb)

Pour éviter le "rebase hell", je me demande comment il serait possible de découpler les données (blog/lignes/compteur/actualité, voir config.json) de la plateforme. Par exemple un autre repo git avec uniquement les données configuré en "submodule" ? Est-ce compatible avec Vercel/Netlify?

[benoitdemaegdt]

Pour éviter le "rebase hell", je me demande comment il serait possible de découpler les données (blog/lignes/compteur/actualité, voir config.json) de la plateforme. Par exemple un autre repo git avec uniquement les données configuré en "submodule" ? Est-ce compatible avec Vercel/Netlify?

Oui ce serait l'idéal. Je ne pense pas que ce soit Netlify le problème, mais @nuxt/content qui va lui chercher la donnée dans le dossier /content du même dépot git. Peut-être que c'est configurable, je n'ai jamais regardé

[XioNoX]

Édit: déplacé par là #406 (comment)

[benoitdemaegdt]

Mmmh c'est peut-être en effet possible avec un vrai git submodule 👍

Ça pourrait résoudre un paquet de soucis d'avoir ce système en place.
@XioNoX t'es chaud d'explorer le sujet et voir si tu arrives à qque chose de généralisable ?

[benoitdemaegdt]

Je vous propose qu'on reste sur le sujet "organisation des forks" ici.

Pour le sujet de la qualité des infras, on peut rester sur cette issue : #406 (comment)