Sortie de Symfony 7.2

Merci marcimat pour cette réponse.

J’ajouterai une chose : le but n’a jamais été de transformer SPIP en application symfony.

Que certains élèments soient pris chez symfony ou ailleurs, oui. Mais c’est posé, réflechi à chaque fois, selon le composant concerné et la maintenabilité interne (pour SPIP) et externe (y-a-til des gens qui maintiennet le composant) ? Voir à ce sujet la discussion en anglais d’il y a peine 3 mois Des nouvelles de Wordpress - #6 par rastapopoulos

Et je risque de me repeter, mais si on pouvait éviter de faire des procès d’intention quand les gens disent et reptent « ce n’est pas notre but », ce serait agréable.

Parceque ces procès d’intention usent moralement et psychniquement à la longue les personnes à qui ces procès sont faits. Et ces personnes sont aussi celles qui tentent, une grande partie d’entre elles bénévolement (elles n’ont pas de client·e, un métier qui ne dépend pas de SPIP) de maintenir cet outil en le rendant compatible avec les différentes evolutions du web.

Pour ne prendre que mon exemple : depuis que j’ai accepté d’etre dans la team maintenance pour soulager marcimat, bruno, james, cerdic (vous vous rendez compte : 4 personnes qui bossaient EFFECTIVEMENT sur l’outil utilisé par 6000 sites), je me prend en permanence des remarques sur « vous voulez allez trop vite » « vous allez vers autres choses que du SPIP ». Alors qu’à chaque fois

  1. On explique le pourquoi et le comment
  2. On documente au max qu’on peut les changements, les implications

Parce qu’on sait que c’est pas facile. On sait que les gens ont du mal à suivre (comme j’ai du mal à suivre personnellement les évolutions des css par ex, mais je ne passe pas mon temps à dire dès qu’il y a une proposition de gérer autrement les css que ca va trop vite). Et donc on essaie de trouver un juste milieur entre évolué (pour ne pas s’user à reinventer la roue à chaque fois) et garder les fonctionnalités publiques telle qu’elles (pour ne pas casser les habitudes des unes et des autres) tout en documentant.

Alors se voir reprocher quasiment toutes les semaines d’avoir un agenda caché, ou encore de ne pas tenir compte des besoins des gens alors que précisément on contribue bénévolement à un outil qui ne nous est pas forcément indispensable, bah ca use. Vraiment. Beaucoup. Surtout quand on repete x fois que non ce n’est pas l’intention.

Alors les ami·es qui utilisent SPIP à usage pro et intensif. Que vous soyez perdu·es, deboussolé, etc je le comprend volontier. Que vous ayez besoin d’aide aussi. Et d’ailleurs ce n’est pas pour rien que j’ai proposé cette année 6 seances de formations (par contre pour ma part j’attend toujours les formations proposés/promises sur des sujets que je ne maitrise pas…). Mais s’il vous plait, arretez de faire en permanence des procès d’intention.

Ou alors un jour marcimat, james, bruno, placido, bricebou et moi meme on arretera de faire des releases usés par ces discours. Et faudra pas pleurer si votre SPIP ne pourra plus s’installer un jour chez votre hébergeur web favori.

D’autant plus que PAR ailleurs il y a plein de domaine autre que du pur PHP dans SPIP qui nécessitent des compétences que vous avez. Par exemple j’ai vu passé pas plus tard que ce matin une réflexion sur les composants web. Je ne sais pas personnelement ce que c’est. Mais je pense que si les gens qui sont compétents dans ce domaine disent « à ce serait une piste à creuser/faire » et bah je leur fais confiance. Je serai un peu perdu à certains moments, mais j’irais pas dire « surtout ne faite pas ca » ou bien « votre projet c’est en fait de faire cela » alors que les personnes ne disent pas ca.

Spip c’est un beau projet qui permet à des gens d’apprendre du web. Mais c’est un projet complexe, parce qu’il melent des gens aux compétences et aux attentes différentes. C’est ce qui le rend à la fois faible et puissant. Essayons d’en garder le meilleur (la diversité des profils) et d’en chasser le pire (la peur face à ce que l’autre fait).

3 « J'aime »