Rationalisation des outils de developpement

Bonjour à tous,

J'ouvre ce topic pour essayer de savoir s'il n'est pas possible de rationaliser un peu nos outils de développements. Je me souviens encore d'une époque déployer une instance de ZdS n'était pas plus compliqué que ça. Aujourd'hui on a une pile de dépendances un peu partout qui rend le setup de ZdS assez lourd, j'aimerai donc qu'on mène une réflexion ensemble pour pouvoir rationaliser/alléger un peu tout ça.

Voici un bref résumé de nos dépendances actuelles :

1. Python : 88% du code, et 24 bibliothèques au sein des requirements.
2. Nodejs : 11% du code, et 22 bibliothèques au sein des requirements.
3. Haskell : uniquement pour l'export pandoc avec Latex et ses copines

Je dois avouer que ma volonté de rationalisation a surtout été motivée par le ressenti de la communauté. Voici un extrait de discussion devant lesquelles on ne peut pas rester de marbre.

Comme vous pouvez le voir, on a une enorme barrière à l'entrée en ce qui concerne la prise en main des outils de dev. Je pense donc qu'il faut s'y pencher avant que ça ne soit trop tard.

L'idéal serait pour moi d'arriver à migrer tout ce qu'on fait avec Nodejs dans du python. Si j'ai bien compris la mécanique, aujourd'hui Nodejs nous permet essentiellement de :

1. compiler les fichiers scss vers css
2. minifier les fichiers js et css
3. créer un sprite d'images à partir du répertoire des images
4. dérouler une batterie de tests de syntaxe des fichiers javascript (et css ?)

Concernant les points 1 et 2 il existe la lib python django-pipeline et son homologue django-pipeline-compass qui, d'après la doc pourrait faire le boulot, ça necessite un POC pour le vérifier.

Je n'ai pas encore regardé pour les points 3 et 4, mais je pense que ça devrait être possible aussi.

J'aimerai donc que ce topic serve à trouver des moyens de remplacement de certaines technos de ZdS qui constituent des barrière à l'entrée du développement.

Concernant haskell et pandoc, qui seront probablement plus présent voir obligatoire a terme pour la génération du HTML, je pensais l'encapsuler dans une class qui permettrai au site de fonctionner avec une version classique de pandoc. En gros que ça puisse fonctionner pour les dev avec le pandoc de base et pas forcément avoir a compiler le fork

J'encourage cette initiative ! Je tiens à dire que j'ai installé les dépendances fronts suite à la discussion, dont un extrait est cité par firm1 dans son premier message. Après quoi, à chaque gulp build, mes images n'ont jamais été correctement affichées sur le site. On m'a vendu cette commande comme "magique", que ça rendait le développement front hyper simple et, au final, je galère.

Au passage aussi, il est censé exister une documentation front. Ca fait plusieurs jours que je la cherche sur le dépôt, en vain.

Au passage aussi, il est censé exister une documentation front. Ca fait plusieurs jours que je la cherche sur le dépôt, en vain.

La doc du front se trouve ici : http://zestedesavoir.github.io/zds-site/ , mais c'est vrai qu'il faudrait la mettre plus en avant. La dernière fois, j'ai passé quelque temps avant de la trouvé.

Au passage aussi, il est censé exister une documentation front. Ca fait plusieurs jours que je la cherche sur le dépôt, en vain.

Elle est ici, en fait c'est une branche orpheline du dépot. Mais bon elle est pas terminé et pas mise a jour depuis 2 mois..

Ton truc, il inclut un truc type livereload ? Nan ? Dommage

Aussi, il compile à la volée ? Et alerte quand il y a une erreur de syntaxe ?

Vérifier la syntaxe JS ? Le seul outil qui existe à ma connaissance, c'est JSHint. Il parrait qu'il nécessite npm + node. Dommage.

Perso, ce que je vois, c'est que niveau de temps d'execution sur travis, on a:

• Install de npm + node + build gulp = 166 sec
• Install de tout ce qui concerne pandoc, latex et autre = 100 sec
• Install des deps pip + tests = 1041 sec

En plus, les dernières builds qui ont fail, c'est à cause des tests python… Dommage!

Je veux bien encore faire un effort, et me débrouiller pour que toute l'installe du front se fasse en 3 étapes:

• installe de npm et node
• npm install
• npm run-script gulp build

Même plus besoin d'installer quoi que ce soit en root. Z'imaginez ?

A noter que comparé au 14 packets (apt) nécessaire au back, plus les 4 (whoo, énorme! Ca devient compliqué!) commandes à lancer (et encore, c'est si on veux pas pandoc, ni le virtualenv.), c'est hyper-light. L'install de npm est même optionelle, puisqu'il existe un pack.zip qu'on vous a gentiement mis à disposition, parce que vous arrêtiez pas de râler

Alors je sais pas. Soit vous faites ce que vous tentez de faire depuis des mois, c'est à dire emmerder les devs front en leur virant leurs outils, soit vous y mettez un peu de bonne volonter, et on garde comme ça.

@Andr0: Tu aurais dû m'envoyer un MP, je te l'aurais reglé, ce problème.

le front

dérouler une batterie de tests de syntaxe des fichiers javascript (et css ?)

c'était là que mon message (qui n'a pas reçu de réponse) venait en fait. A quoi bon tester du js/css alors que le code n'a pas été modifié?

Sans compter que sur travis, npm/gulp ne sont pas très stables.

Enfin, comme déjà dit auparavant, npm and co ne sont que des outils de build, ils ne servent qu'à ça. C'est une tâche énorme et vraiment utile, je ne le nie pas et ne cherche pas à supprimer ces outils. Néanmoins, avoir des outils de build sur chaque env de dev, c'est relou et force est de constater que tout le monde n'arrive pas à les installer et que sauf sur windows, la commande gulp build ne fonctionne pas. Et je ne semble pas être le seul. C'est amusant une fois ou deux de devoir envoyer le .zip via owncloud mais à force ça gonfle.

Je veux bien m'amuser à mettre en place un serveur de build sur mon dedié pour que tout le monde en profite, tout cloisoner avec un chroot c'estp as la mort. Mais pour que ça marche il faut qu'il y ait une vraie adaptation derrière.

Actuellement les outils front, c'est pas la joie.

le back

Le back est un poil plus complexe à comprendre puisqu'il mélange allègrement l'utilisation de logiciels tiers style pandoc, des adaptateurs codés à la main (git python), et des codes parfois déjà refactoré, parfois hautement dupliqué (article vs tuto, routine de publication des tutos dans les tests unitaires…)

Il faut y ajouter Pillow qui parfois nous envoie chier, lxml qui se casse plus vite qu'un pare brise carglass…

La force du back c'est qu'on a tenté de ne pas toujours réinventer la roue et que nous sommes très dynamiques grâce à une équipe assez nombreuse (8/9 gros contributeurs) mais c'est aussi notre faiblesse face aux 2-3 contributeurs du front.

Nous venons tous d'expériences différentes, pour ma part, par exemple, je n'ai jamais touché à django avant zds et je n'ai toujours pas suivi le moindre tuto à ce propos, je me suis plongé dans le code, point. Là où ça pose problème, c'est que cela crée des styles de code très différents et sur des fonctionnalités volumineuses. En ce sens la ZEP 12 (puis la ZEP 8) sera un vrai indicateur de la force de l'équipe si on arrive à la mener à bien. Mais entre le module tuto presque 100% codé par firm1 (allez, 80% doit être une bonne approximation), le module membre qui vient de recevoir une rustine énorme avec la désinscription, les premières ZEP qui arrivent (pandoc, demande d'aide), les features non zep (message de commit, validation partielle) on est en train de produire une montagne de code dans laquelle il est difficile d'entrer.

notre vraie bouée a été l'énorme travail réalisé pour :

• pep8
• la doc, et la doc back est juste ENORME. Bravo à tous.

Et si au lieu de gueuler a tout va parce que "machin veut me retirer mes outils" et "tout le monde est mechant envers les dev' front" on bossait ensemble a ameliorer les choses ?

Ton truc, il inclut un truc type livereload ? Nan ? Dommage

Sorti du ton de ton message qui est clairement en mode casse-couille ferme d'esprit, c'est un truc comme ca que tu cherches ? https://github.com/lepture/python-livereload

Vérifier la syntaxe JS ?

Comme ca ? https://pypi.python.org/pypi/NoseJS

Perso, ce que je vois, c'est que niveau de temps d'execution sur travis, on a:

Et un plantage 20% du temps donc faut relancer a la main

L'install de npm est même optionelle, puisqu'il existe un pack.zip qu'on vous a gentiement mis à disposition, parce que vous arrêtiez pas de râler

J'ai essaye, j'ai pas l'image et j'ai reussi a foutre le merdier dans mon dossier. Apres ca fait aussi une barriere a l'entree pour ceux qui veulent faire un peu de dev' front.

Alors je sais pas. Soit vous faites ce que vous tentez de faire depuis des mois, c'est à dire emmerder les devs front en leur virant leurs outils, soit vous y mettez un peu de bonne volonter, et on garde comme ça.

Autre idée, on arrête de considérer que c'est back VS. front et on bosse tous ensemble, en arretant de precher pour sa paroisse (Node.js <3 ) afin de garder un esprit ouvert ? Il va un moment falloir arreter de penser que parce que Node deplait a qqun alors il est forcement contre les devs front et leur choix.

Wow, je suis horrifié de voir ta réponse Sandhose. Ca ne me donne même pas envie de débattre sur le sujet. Je vais faire comme avant, rester loin du développement front et tout se passera bien.

Je les ai oublié ces deux là et tu fais bien de le noter. Je crois que l'étape d'après va consister à trouver comment se débarasser de lxml. Tout ceux qui y l'ont touché savent bien que c'est une torture.

Je plussoie explicitement ce paragraphe d'Eskimon.

Je suis incapable de dire tout ce que fait la machine du front-end actuel, mais si tu pouvais les ennoncer comme tu viens de commencer, ça permettrait de voir si aujourd'hui il n'existe pas des alternatives dans le monde python afin de centraliser au mieux la chose. Et d'attirer peut-être d'autres contributeurs

Mon rêve serait que ZdS s'installe sur chaque pc en une commande, mais ça c'est un rêve, mais s'en approcher est possible.

Me concernant, aux fails réguliers de travis pret (mais a qui est la faute ici?), la présence de node.js comme outils fronts ne me dérange et choque pas. Si ces outils sont nécessaire, pas de soucis. Je vais donc passer outre l'agressivité inutile de sandhose et essayer d'etre constructif. Personnellement ce n'est pas la présence de ces outils qui me gène. Ce qui me pose le plus de problème actuellement c'est les contributions.

Après plusieurs mois d'ouverture le constat est assez simple :

• Sur le back on a plusieurs contributeurs réguliers et des PR de contributeurs ponctuels
• Sur le front, Alex est (etait?) le seul a pousser régulièrement + sandhose au début.

Le back n'est pas parfait, la barrière à l'entrée est assez élevée mais force est de constaté que c'est moins pire que sur le front.

Je ne critique personne et ne veux pas pointer des gens du doigt mais on a un problème sérieux. Alex a réduit récemment ces contributions (entre autre lié a son nouveau taf). Le fait est qu'on a actuellement PLUS UN SEUL contributeur front régulier. Même si Alex dégage du temps, on aura toujours un gros problème. Les contributeurs qui ont tentés de toucher au front ont souvent mal fait les choses et ont dut être corrigé par Alex. Mais on ne va plus pouvoir tenir comme ça.

Donc je me fout un peu des raisons et ce qui nous ammené là mais on a un problème sérieux car on a plus de dev front et que manifestement aucun contributeur ne peut s'y mettre. La différence de contributions est je pense assez importante pour que tout le monde s'en rende compte. Il faut donc trouver une solution !

C'est le problème, et il n'est pas spécifique au front, seulement plus marqué. Les débutants et, plus généralement, les nouveaux contributeurs ont peur, du moins c'est mon cas, de faire perdre plus de temps qu'autre chose. A quoi bon écrire du code si c'est pour se rendre compte qu'il est mauvais et que quelqu'un devra le refaire ? Côté back, le nombre de contributeurs compense puisque l'accompagnement est plus présent (même si, en fin de compte, ce sont toujours les mêmes qui commitent). Côté front, ce n'est pas le cas.

Du coup, le problème majeur a réglé, c'est la formation des nouveaux contributeurs. Dire que tout le monde peut participer, que le site est OpenSource… ainsi que des articles comme celui sur la page d'accueil, ça attire plein de gens, mais ces derniers sont rapidement repoussés par les issues dans tous les sens, le volume du projet, la complexité de sa structure, de son installation… Après, je ne suis pas contributeur donc j'ignore si ça provient d'un manque d'organisation interne ou pas, mais je pense qu'il est indispensable de clarifier le projet, son organisation, le code, les rôles de chacun…

Je n'ai aucune expérience en gestion de gros projet, je ne contribue pas au code et il ne s'agit que de mon opinion, mais peut-être serait-il préférable de poser clairement les bases (à définir) avant de vouloir implémenter de nouvelles features. Au bout d'un moment, le projet sera trop développé pour le faire et seuls les habitués pourront participer. Pour les bases, les points suivants pourraient en faire partie :

• Une documentation claire et complète

Première chose, expliquer l'installation du site de sorte que ce soit simple à effectuer (cf : ce sujet) : les contributeurs au code sont bénévoles et ne souhaitent pas nécessairement faire cent mille réglages avant de pouvoir apporter leur pierre à l'édifice.

Éclaircir la structure globale du projet, l'agencement des dossiers et des fichiers. Bien que les noms soient explicites, il faudrait pouvoir atteindre la partie du code ciblé quasiment sans chercher.

Expliciter les concepts. Un tutoriel, comment c'est représenté ? L'éditeur markdown, il repose sur quoi ? Etc.

• Une organisation solide

Premièrement, faire le lien entre le forum (Bugs et Suggestions ainsi que la Dev Zone) et Github (sans compter IRC). Certains problèmes sont répertoriés sur l'un et pas sur l'autre, certains débats ont lieu sur l'autre et pas sur l'un… Pour peu qu'on soit étranger à Github, on ignore ce qui est en cours, qui s'en charge, comment…

D'autre part, même si je ne suis pas du tout un expert en la matière, je pense qu'il faut structurer la gestion des problèmes. Des issues sont ouvertes à tout va, certaines ZEPs sont commencées par certaines personnes… Personnellement, j'ignore comment intégrer une équipe de résolution (i.e. participer à telle issue). D'ailleurs, souvent, j'ai l'impression, quelqu'un se lance bille en tête et les autres ne peuvent pas faire grand chose autre que de la QA. Pour les problèmes mineurs c'est pas gênant, pour les ZEPs par exemple, un peu plus.

Enfin, et ça découle du point précédent, il faut dire à chacun ce qu'il peut faire et comment, en particulier aux nouveaux contributeurs. Il y a des tonnes de choses à effectuer mais, bon sang, je fais quoi moi ? Je m'inscris sur une liste de participants ? Je commence dans mon coin et me rends compte que quelqu'un s'en est déjà chargé ? Je code sans en parler aux autres et expliquer ce que j'entreprends, histoire qu'ils aient bien de la peine à m'aider ?

En particulier, je pense que la manière dont seront implémentées les ZEPs n'est pas assez claire. Par exemple, pour la refonte du traitement markdown, on a tout ce qu'on souhaite faire dans le premier message, mais pas comment on va le faire. Du coup, il n'y a que Kje qui sait où il en est et comment il compte s'y prendre (sauf si j'ai manqué quelque chose, mais si c'est le cas, c'est que cette chose gagnerait à être plus visible).

• Un code propre

Une fois qu'on a déniché le fichier auquel on souhaite apporter des modifications, on aimerait bien comprendre le code rapidement. Pour cela, il faut qu'on ait des repères, ce qui n'est possible qu'avec un code uniforme. D'où : un code en anglais (par exemple, mais ça me semble nécessaire) et respectant des conventions (PEP8 obligatoire). En outre, les commentaires sont indispensables : ils permettent d'éclairer les passages obscurs et un peu techniques mais aussi de se déplacer rapidement parmi les fonctions.

Une PR ne devrait pas être mergée si elle ne respecte pas ces critères (et/ou d'autres).

Modestement.

Je ne peux qu'appuyer les propos de Vayel

Je me suis dis c'est cool, c'est open source, c'est en python (un langage que j'utilise quotidiennement) donc je vais voir si je peux aider et pourtant rien que l'étape d'install m'a fais faire demi tour
Je ne vais pas répéter ce qu'à dit Vayel mais je suis d'accord à peu près avec tout !

Le fait est qu'on a actuellement PLUS UN SEUL contributeur front régulier.

https://github.com/zestedesavoir/zds-site/pulls/Alex-D

https://github.com/zestedesavoir/zds-site/pulls?q=is%3Apr+author%3AAlex-D+is%3Aclosed

Suffit de regarder les dates pour voir que je ne suis plus H24 sur le projet mais je suis toujours là

Pour ce qui est des difficulté rencontrées avec node, j'ai dev tout le mois de juin pendant mon stage sur une machine sous Fedora, j'ai déjà dev sur Win7, 8 et 8.1, Debian squeeze et très honnêtement, j'ai quasiment (pas au début du projet) tout qui a toujours fonctionné assez rapidement (front comme back).

Mes seuls soucis ont été des dépendances back manquantes ou un peu bancales genre lxml (comme l'a dit firm1).

et que manifestement aucun contributeur ne peut s'y mettre.

La vraie question que je me pose c'est : "ne peut" ou "ne veut" ? Ce que je constate c'est que sur le back il y a une inertie, les gens s'aident. Sur le front quand Sandhose a déboulé nous avions échangé et il avait pu rapidement se mettre en marche. Donc si un contributeur le souhaite réellement il peut contribuer au front. Jusqu'ici le soucis est que ce sont des développeurs back qui ont tenté de toucher au front et que ça donne le même résultat que quand je vais trifouiller dans le back : c'est pas optimal et quelqu'un repasse derrière.

Je n'ai pas l'impression que les outils (quels qu'ils soient) soient un frein au développement. J'ai juste l'impression que l'on manque de personnes qui ont du temps à accorder au projet.

Je serais ravis d'aider quiconque voudrait contribuer au code front. Mais il faut garder à l'idée que ça n'est pas aussi simple que ça en a l'air, c'est certainement le problème que je rencontre le plus. Beaucoup pensent que le front c'est "juste du HTML et du CSS" alors que c'est, sur un projet comme ZdS, un peu plus que ça : templates, HTML sémentique, métadonnées, SCSS, JavaScript, … Je suis d'accord pour rendre le projet accessible aux contributeurs, mais il faut bien se rendre compte qu'il faut quand même de solides bases pour s'attaquer à un morceau tel que ZdS (ça vaut pour le front et le back).

Remplacer les outils basés sur Node.js par des outils basés sur Python

J'ai envie de dire : pourquoi pas. Si les outils sont équivalents et tout aussi performants. Chez moi, quand je dev sur ZdS, le refresh du style est instantané au Ctrl+S. Si Python sait faire ça, je ne dis pas non.

Maintenant il faut quand même être conscient qu'un dev front sera globalement infoutu de bidouiller les scripts Python tel qu'on le fait actuellement sur le Gulpfile.js. Aussi, j'ai node.js sur toutes mes machines. Je n'ai pas Python sur toutes mes machines, mais à ce niveau là il me semble que Python est déjà sur la plupart des systèmes UNIX, du coup il ne reste que le problème de Windows : pas de chance c'est ce qui est pas mal utilisé par les devs front (Photoshop, toussa).

Ce que je veux dire c'est : je suis pour, si c'est équivalent et si des gens sont compétents là dessus et qu'ils seront prêts à maintenir toute la machinerie qu'on a mis plusieurs semaines à mettre en place via node.js.

Que font les outils front ?

Je suis incapable de dire tout ce que fait la machine du front-end actuel, mais si tu pouvais les ennoncer comme tu viens de commencer

Il l'a déjà fait, donc je me contenterais de le citer car il a détaillé tout ça sur Github :

• gulp: Task-runner qui "orchestre" tout le build, selon le Gulpfile.js
• gulp-autoprefixer: Permet de préfixer automatiquement le CSS pour assurer la compatibilité avec la plupart des navigateurs
• gulp-cache: Permet de "mettre en cache" une partie du build, pour gagner du temps
• gulp-clean: Plugin pour supprimer un dossier/fichier (gulp clean supprime le dossier dist/)
• gulp-concat: Permet de fusionner plusieurs fichiers (ex: les différents fichiers JS
• gulp-imagemin: Optimise les images
• gulp-jshint: Vérifie la syntaxe du JS
• gulp-livereload: Plugin utile au développement ; permet de "recharger" le JS/CSS pendant l'édition, sans recharger la page manuellement
• gulp-minify-css: Minifie le CSS
• gulp-newer: Détermine si un fichier a été modifié ou non (s'il faut le recompiler ou non)
• gulp-rename: Permet de renommer un fichier (genre main.css -> main.min.css)
• gulp-sass: Compile les fichiers SCSS en CSS
• gulp-size: Affiche dans la console la taille de certains fichiers
• gulp-uglify: Minifie le JS
• gulp-zip: Permet la création d'un zip (en l’occurrence, le pack.zip)
• gulp.spritesmith: S'occupe de la création du sprite
• jshint-stylish: Affichage des erreurs JSHint
• main-bower-files: Utilisé pour "récuperer" les fichiers des dépendances bower (type jQuery ou autre)

En gros, quand je me mets à bosser sur ZdS, je lance :

• une console avec gulp : ça tourne en continue, ça m'affiche en live les erreurs de syntaxe, les fichiers qui ont été recompilé, le poids des fichiers (important pour l'opti), et ça balance tout ça à LiveReload qui met à jour mon navigateur sans recharger la page (rechargement asynchrone).
• une console avec python manage.py runserver 0.0.0.0:3000 : ça lance le serveur de ZdS accessible n'importe où, pratique pour les tests sur mon smartphone via le réseau local.

Ça me semble être le minimum syndical. Admettons qu'on remplace le gulp par python notrejoliscript.py il faudrait qu'il soit au moins équivalent.

J'espère n'avoir laissé dans mon message aucune animosité et souhaite que des solutions soient trouvées à ces problèmes qui sont visiblement récurrents depuis un an déjà.

Merci Vayel pour ce retour de quelqu'un qui n'a pas la tête dans le cambouis (quand je te lis ça parait tout à fait logique), ça permet de savoir précisément ou mettre l'accent pour aider les personnes extérieurs à mettre le nez dans le projet.

D'ailleurs, je t'invite (ainsi que tout ceux qui sont dans la même situation) à participer aux Zest'Meeting afin de nous aider à cerner les barrière à l'entrée.

Ç’aurait été avec plaisir, mais je suis indisponible en semaine, la Math Spé devant occuper toute mon attention. Bref, peu importe, mais pour dire que mon message précédent n'est pas à prendre comme un "il y a des problèmes mais débrouillez-vous pour les régler". =)

Pour l'install qui fait peur, à mon avis on a déjà fait une erreur de comm' dans toutes nos présentations de "comment installer ZdS" : elles sont faites pour le débutant total qui arrive sur son premier projet Django.

Du coup, on commence par fait installer douze milliards de dépendances / outils qui sont utiles à tout projet Python, mais que le contributeur un minimum habitué a sans doute déjà chez lui (comme python-dev). Ca fait des procédures qui sont effrayantes.

Une solutions serait déjà de re-présenter les choses, avec "les infos minimales pour un développeur Python" ; puis des modules genre "je n'ai jamais développé en Python, que dois-je installer", "je veux contribuer au front", "je veux pandoc fonctionnel", etc.

@Alex : Comme je l'ai dis, ce n'est pas parce que tu as du temps que mon propos est invalide. Il se passe quoi le mois où tu as un rush au boulot ? On a plus de front pendant un mois ?

Au début du projet on avait une ultra dépendance à firm1 pour le back et manifestement on a réussi a passé outre. Les semaines où firm1 n'est pas dispo, ça avance tout de même.

La vraie question que je me pose c'est : "ne peut" ou "ne veut" ? Ce que je constate c'est que sur le back il y a une inertie, les gens s'aident.

Ça c'est la conséquence, c'est plus facile de s'entraider qu'en on est plusieurs.

Sur le front quand Sandhose a déboulé nous avions échangé et il avait pu rapidement se mettre en marche. Donc si un contributeur le souhaite réellement il peut contribuer au front.

J'ai tout de même du mal à croire qu'on arrive a une telle différence de contribution par pur hasard, simplement parce qu'il n'y aurait pas sur ce site d'autres personnes qui aiment / font du front. De plus en plus j'ai l'impression que Sandhose est "l'exception qui confirme la regle". Ce n'est pas contre toi, ni contre personne, mais il y a un soucis quelque part. Ce n'est pas normal je pense qu'il n'y ai eu QU'UNE SEULE PERSONNE à s'y mettre. Il y a un problème d'accessibilité clair.

Jusqu'ici le soucis est que ce sont des développeurs back qui ont tenté de toucher au front et que ça donne le même résultat que quand je vais trifouiller dans le back : c'est pas optimal et quelqu'un repasse derrière.

C'est peut être là le problème ? Qu'on soit quelqu'un qui vient du back, ou un premier contributeur externe, c'est pareil : on ne maitrise pas encore entièrement tous les outils dispo. firm1 a probablement repassé plusieurs fois derrière eskimon, artagis ou spacefox. Il y a encore quelques jours il commentait une PR d'andro. C'est normal qu'au début les gens ne soient pas totalement opérationnel, parce que chaque module est complexe.

Je n'ai pas l'impression que les outils (quels qu'ils soient) soient un frein au développement. J'ai juste l'impression que l'on manque de personnes qui ont du temps à accorder au projet.

Je suis d'accord avec ça, les outils ne sont a mon avis qu'un problème mineur. le manque de contributeur est le vrai problème et je cherche justement à comprendre POURQUOI il y en a si peu sur le front.

Je serais ravis d'aider quiconque voudrait contribuer au code front. Mais il faut garder à l'idée que ça n'est pas aussi simple que ça en a l'air, c'est certainement le problème que je rencontre le plus. Beaucoup pensent que le front c'est "juste du HTML et du CSS" alors que c'est, sur un projet comme ZdS, un peu plus que ça : templates, HTML sémentique, métadonnées, SCSS, JavaScript, … Je suis d'accord pour rendre le projet accessible aux contributeurs, mais il faut bien se rendre compte qu'il faut quand même de solides bases pour s'attaquer à un morceau tel que ZdS (ça vaut pour le front et le back).

Comme tu le dis il y a le même problème pour le front. Je ne dénigre pas du tout la difficulté des techos utilisés sur le front en posant ces questions. Le back n'est pas plus simple et pourtant des gens qui n'avaient presque jamais fais de python ou django arrivent a contribuer de manière utile.

Bref je ne sais pas trop quoi en penser. Perso j'ai jamais même tenté de toucher au front vue que j'ai des gouts artistiques de chiotte. Mais je trouve dommage que tous ceux qui ont tenté se soient cassés les dents ou de lire "je vais continuer de me tenir loin du front".

Mais j'en reviens au même problème, quelque soit la cause il nous faut une solution. On a une hyper dépendance a Alex sur le front et ce n'est pas viable pour le projet. Ce n'est pas personnel à la personne, c'est la dépendance à une personne unique. Je suis aujourd'hui soulagé que sur le back firm1 ne soit plus le seul a pouvoir intervenir deçu et c'est aussi pour ça que je demande régulèrement si des gens pouvaient m'aider sur Pandoc : ce n'est pas que je ne me sent pas de le faire, c'est que je vais être le seul à maitriser ce morceaux.

EDIT :

En particulier, je pense que la manière dont seront implémentées les ZEPs n'est pas assez claire. Par exemple, pour la refonte du traitement markdown, on a tout ce qu'on souhaite faire dans le premier message, mais pas comment on va le faire. Du coup, il n'y a que Kje qui sait où il en est et comment il compte s'y prendre (sauf si j'ai manqué quelque chose, mais si c'est le cas, c'est que cette chose gagnerait à être plus visible).

Heu… le premier message de la ZEP explicite le problème de base, la solution retenu et ensuite les solutions qui n'ont pas été retenu (pour référence). La discussion au début a porté sur le choix de la solution.

Depuis que Pandoc a été choisi, j'ai posté régulièrement pour dire où j'en étais.

C'est probablement pas clair mais je ne vois pas trop ce que je peux changer.

Je vais mettre les pieds dans le plat, en tant que témoin attentifs des événements mais qui n'a pas la tête dans le guidon pour autant (et pour cause, je ne développe pas) : je pense que l'un des problèmes majeurs vient de l'accueil absolument pourri qu'ont reçu les quelques personnes ayant commencé à toucher au front. Et même avant de commencer à y toucher, quand on voit les réactions pleines de mauvaise fois, de déni, de prétention incroyable, voir de méchanceté (tous ces mots sont pesés) d'Alex-D, alors je comprends parfaitement que les dev front qui passent par ici n'aient pas (ou plus) envie de participer. Surtout si c'est pour avoir ce même Alex-D comme "superviseur", ne serait-ce que dans les premiers temps. Quand Sandhose est arrivé, beaucoup avaient cru qu'il allait repartir aussitôt ! Puis quand je lis son message plus haut, je comprends mieux pourquoi il est resté. Ce ton méprisant est insupportable, Sandhose.

Alors voilà, ce n'est pas politiquement correct de balancer comme cela, mais au bout d'un moment il faut arrêter de tourner autour du pot, il faut dire les choses. Donc oui, je pense très sincèrement qu'il y a un problème de personne. N'en déplaise à tous les fanboys d'Alex-D (parce que son CV, bah il est trop claaaasse). Attention, je ne dis pas que c'est le seul problème, loin de là. Tout ce qui a été évoqué dans ce sujet (doc front incomplète, lourdeur ou mauvaise approche de la doc d'install, multiplicité des outils, etc.) est primordial. Mais si on doit faire la liste des problèmes, alors le problème de comportement exécrable d'Alex-D en équipe en est un.

Comme je l'ai précisé, je ne suis pas du tout un expert en gestion de projet informatique et ce que je vais dire pourra paraître absurde, mais peut-être faudrait-il décrire en détails comment on souhaite convertir en code la solution adoptée, histoire qu'à la fin, ça ne reste presque plus qu'un problème de dactylographie et de connaissance technique du langage. Et puis, ajouter tout ça dans le premier message, que ce dernier contiennent ce qui a été décidé, pourquoi ça l'a été et où ça en est actuellement (ce qui a été fait, par qui, et ce qu'il reste à faire, par qui).