Organisation des forks - Githubissues

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)

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 ?

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 ! :)

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.

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 ! :)

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.

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 895d2e4d044d286a4acca2c4e1883dbb320fc23b, 752aa5fc3a1636aa1906e838e5467645084966a3, bea8b8bc57c842e39d343b6873f00e46d90df0d9, 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.

benoitdemaegdt / voieslyonnaises

Organisation des forks #431