Organisation des forks #431
Comments
|
Hello @TFCx 👋 Merci pour cette issue, c'est un sujet important 👍
Super classe, j'adore les différentes visualisations (qualité, type, avancement) 👏
Pas hyper évident comme sujet haha 😅 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.
Allez, je commence à être convaincu par le MM de la FUB 😄
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 😄 |
|
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". |
|
Hello, Je rejoins totalement @XioNoX. Par défaut, cette fonctionnalité est désactivée et il suffit de passer le boolean J'espère que cela fera avancer le débat |
|
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 |
|
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. |
|
Hello @TFCx 👋
Oui en effet, ça s'annonce fastidieux 😓
ça me va bien de pouvoir activer / désactiver une fonctionnalité depuis le config.json. |
|
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? |
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é |
|
Édit: déplacé par là #406 (comment) |
|
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. 
|
|
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) |
|
Hum, du coup chaque fork pointerait vers un sous-module différent (un fork des données) ? Tu vois quel avantage à faire ça ? Attention, on complexifie aussi la gestion du dépot (genre, des relatifs débutants se perdront avec Ce que je fais pour le fork montpellier :
On pourrait imaginer que dans le dépôt de lyon, il y ait
Du coup :
|
|
Yes, ça me semble être un bon compromis ! |
|
Une autre solution, moins propre, c'est de vivre avec les données lyonnaises mais de ne pas y toucher. cf Il faut ensuite changer 2-3 éléments dans le code pour pointer sur le bon dossier. |
|
Cette dernière solution pourrait même permettre de visualiser tous les REV en une seule fois 🤣 |
À voir, j'ai pas masse de temps :(
Ne pas avoir à gérer les conflits des changements de données.
Oui c'est le désavantage, à voir à quel point ça serait galère. À comparer avec les autres options. Mais ta suggestion d'hier semble top !
Je suis moins fan de cette option du fait du coté moins propre, ou alors il faudrait faire la même chose avec le blog, les compteurs, etc. |
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
Piniaqui 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/nomdemavillepar 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 desCyclopolis Lyon,Cyclopolis Montpellier, etc. Ou queCyclopolisne soit la marque de l'observatoire vélo que de Lyon ? (poke @ThibautChd @Delapouite)The text was updated successfully, but these errors were encountered: