Une étude de l'attractivité de Zeste de Savoir : le cas de la technique

Chouette billet, ce qu’il raconte est moins chouette, mais pas inattendu, malheureusement.

Le nombre de commit est une métrique qui a un peu changé de sens, note, parce que maintenant, on squashe les commits, ce qui était pas le cas au début.

Et vous, qu’est-ce qui vous a motivé au départ à contribuer à la technique de Zeste de Savoir ?

L’envie de voir des nouvelles fonctionnalités arriver

Et pourquoi avez-vous abandonné ?

Le teeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeemps ! Y’a que 24h dans une journée, et il en faudrait au moins le double pour tout ce que je veux faire Du coup, j’ai des épisodes de contributions. D’ailleurs, je compte remettre une pièce dans le juke-box bientôt.

Je me demande jusqu’à quel point ZdS ne bénéficierait pas de fluidifier le processus de développement. Pourquoi pas ne pas essayer de faire du rolling release, par exemple, avec une mise en prod mineure par semaine ? Il y a un risque évident d’augmenter le nombre de bugs, mais comme de ce que j’ai compris des retours des gens, les tests en beta ne sont plus assurés par des volontaires… L’avantage, ça serait de réduire le temps entre le merge et la mise en production, et donc potentiellement augmenter la motivation ?

Pareil, il y a actuellement 32 PR ouvertes sur le repo, dont beaucoup plus ou moins abandonnées. Est-ce que ça ne vaudrait pas la peine de faire un gros ménage ?

Billet très intéressant, bien que certains graphiques soient assez inquiétants pour le long terme…

Au passage, il semblerait que je n’apparaisse pas dans l’histogramme de durée entre le 1er et le dernier commit. Peut-être que certains ont échappés à la méthode de collecte de données utilisée ?

@rezemika Je me disais la même chose, j’ai fais 2–3 PR espacés dans le temps Sans prendre en compte mon compte supprimé.

(Je sèche un peu pour le Tweet que j’ai prévu demain, quelqu’un a une suggestion ?).

Billet très intéressant, bien que certains graphiques soient assez inquiétants pour le long terme…

Une extrapolation linéaire me fait dire qu’il y aura, en 2019, 0 contributeur au code de ZdS.

La mise en place d’un Docker Compose. Cela permettrait aux éventuels contributeurs ne pas perdre de temps dans la mise en place de la stack technique.

C’est une remarque à titre personnel. Quand je vois la documentation pour installer l’environnement, cela me semble être le parcours du combattant. Bon j’exagère surement mais avec Docker il suffirait de faire une seule commande pour builder une stack entière avec les bonnes versions utilisées (Python, Node, Java, etc) et sur n’importe quel OS, je me dis que cela pourrait en motiver plus d’un à s’investir dans l’évolution du site.

Ha ? L’installation se fait avec (ici sous Ubuntu) :

make install-ubuntu

Et c’est tout. Le point qui est dommage, c’est que cette commande n’est pas la première indiquée dans la doc.

J’ai de plus en plus l’impression que certains sont perdus s’ils n’ont pas leur petit Docker.

Pourquoi pas ne pas essayer de faire du rolling release, par exemple, avec une mise en prod mineure par semaine ?

@lthms : Même au sein de l’équipe technique, il n’y a que quelques personnes à avoir accès au serveur de production et à avoir les compétences techniques pour mettre en production une nouvelle version. Et si je ne me trompe pas, ces membres là manquent de temps pour faire des mises en production plus régulières. On voit bien le temps qui s’est passé entre la mise en production de la v26 (décembre 2017) et la v27 (juillet 2018). Mais je pense comme toi que des mises en production plus régulières pourraient dynamiser un peu plus le développement du site web. Une autre amélioration serait aussi de mieux planifier le développement en se donnant des objectifs pour chaque version (une date pour la mise en production, telles nouvelles fonctionnalités et tels bogues corrigés) et en suivant plus précisément le développement des PRs ?

Le point qui est dommage, c’est que cette commande n’est pas la première indiquée dans la doc.

Effectivement la documentation aurait bien besoin d’un coup de neuf pour les instructions d’installation !

Article intéressant !

Personnellement, je suis intéressé par le développement de ZdS, mais je ne sais pas vraiment quoi faire. Je lis à droite à gauche sur ZdS qu’il y a plein de fonctionnalités prévues, mais où peut-on trouver une liste ?

De plus, je ne sais pas vraiment comment faire, et j’ai peur de faire des choses qui ne respecteraient pas le workflow… Il serait peut-être sympa que quelqu’un fasse un tutoriel (je pense que la vidéo serait le meilleur format) où on le suit réaliser tout le processus d’un fix ou du développement d’une nouvelle fonctionnalité (de la détection du besoin à la pull-request, en passant par la création de la branche sur Git, de la réalisation des tests, etc).

Je sais, on va me dire qu’il y a le guide du contributeur, un peu de doc pour découvrir comment contribuer, etc. Mais je trouve qu’une fois qu’on a lu toute cette documentation, on se sent un peu tout seul, un peu à se dire: "je fais quoi maintenant ?"…

Du coup, cela m’amène à une autre question: les développeurs de ZdS ont-ils un espace de communication dédié ? Les rares fois où je suis allé sur IRC, c’était complètement vide et le forum du Dev de ZdS n’est pas très pratique pour des discussions interactives très spécifiques au développement de ZdS (on y propose plus des idées et on en discute, pas vraiment de leur implémentation). Je me vois mal ouvrir un nouveau sujet à chaque fois que j’ai une interrogation sur le code de ZdS…

Autre point, je suis pas mal intéressé par l’administration système, c’est pour ça que j’ai suivi le thread du lancement de la v27. Tout semblait un peu en pause et un beau matin j’ai vu que "ok c’est déployé". Je vous avoue que j’en étais un peu frustré, j’ai pas eu l’impression que ça révélait un véritable travail d’équipe (je sais, pas besoin d’être 42 pour faire une mise en prod !). Là encore, j’aurai aimé, pourquoi pas, une petite vidéo de la mise en prod (mais je sais bien que ça demande du temps…)

Et on en revient encore au temps, malheureusement, je pense qu’il nous en manque à tous…

J’ai beaucoup parlé de vidéo dans ce commentaire, j’aimerai bien par exemple qu’il y ait d’autre live vidéo (ou pas forcément en live !) du développement d’une fonctionnalité, ou de la résolution d’un bug, comme ça a déjà été fait dans le passé. Ça permet de montrer comment le code est organisé, comment fonctionne le workflow, et ça montre sans doute aussi que ce n’est pas si difficile que ça de contribuer au code de ZdS !

Un aspect important qui je pense est important, c’est l’évolution de la complexité. On peut pas vraiment comparer un commit de 2014 avec un commit de 2018. Au début il était rapide d’itérer, maintenant ca devient plus difficile de corriger les bugs et les nouvelles fonctionnalités sont moins triviales aussi

~~J’ai hâte une fois que j’aurais finit : d’apprendre python, la programmation orientée objet et Django, de contribuer au code de ZdS.

Sinon merci pour ce billet, il nous apprend un peu plus le fonctionnement du site.

Pourquoi perdre son temps à essayer de configurer le zds alors qu’il y a des solutions clés en mains comme PHPBB ou MYBB qui ont une interface administrateur ?

Effectivement, je ne l’ai pas mentionné dans le billet. ça peut expliquer la grosse différence entre 2015 et 2016 au niveau de la quantité de commits.

Je dirais clairement que oui. Mais si j’en crois mes propres graphiques, il n y a plus assez de contributeurs pour faire ce ménage. On est dans le piège du chat qui se mord la queue.

Bien vu. Dans mon script, je vois que j’ai considéré le mauvais champ de commit. Un commit étant associé a deux type d’acteurs, l'author et le committer. Mon script a pris en compte le committer au lieu de considérer l'author.

Je mets à jour le billet d’ici peu. Mais ça ne change pas beaucoup de chose au final (on voit surtout apparaître des contributeurs qui n’étaient pas comptabilisés).

Je ne suis pas sur d’avoir compris ton message. Je manque un peu de contexte.

Attention : cette commande ne fait qu’installer les dépendances systèmes. Il faut encore faire : make install-back install-front. Mais oui l’installation a été grandement simplifiée depuis.

Je dirais clairement que oui. Mais si j’en crois mes propres graphiques, il n y a plus assez de contributeurs pour faire ce ménage. On est dans le piège du chat qui se mord la queue.

J’ai un peu bossé hier, et on est passé de 32 à 20 PR, dont 10 effectivement mergées. Non mais

J’ai mis à jour le billet en corrigeant le bug de mon script. Les conclusions font un peu moins peur finalement, même si on est toujours sur une pente difficile.

Je pense que le problème majeur pour les nouveaux contributeurs est de mettre le pied à l’étrier. Il y a quand même un bagage technique assez important à avoir. J’ai l’impression que les développeurs plus expérimentés ont tendance à l’oublier.

Avant de contribuer, on va dire que j’avais de la culture sur :

• la programmation scientifique en Python (via un usage personnel sur de petits projets),
• les grands principes des gestionnaires de version (usage basique de SVN pour quelques bricoles),
• le développement web (back, front, template, framework et tout le toutim, parce que je traîne sur ZdS).

Pour faire ma première contribution, qui étaient très mineure, j’ai dû :

• m’inscrire sur Github et forker le dépôt,
• apprendre à me servir de Git, notamment les spécificités du workflow de ZdS,
• installer l’environnement de développement back et front (ce qui n’a pas été flowless),
• comprendre un peu la structure du projet Django (notamment où sont rangés les templates),
• trouver le fichier qui va bien (template du message aux nouveaux inscrits), le modifier,
• trouver (et c’était pas évident) là où sont définies les variables qui sont injectées dans le template et les modifier,
• apprendre à me servir de Github pour faire une PR, (ce qui est pas forcément immédiat non plus, même si relativement simple).

Je me suis démerdé tout seul, ça m’a pris des heures, et j’ai du jongler entre différentes pages de documentation, que ce soit sur le forum ou sur la doc de ZdS ou le readme sur Github et j’en passe. Il n’y a pas un seul endroit où toutes les infos sont dispo pour partir de presque zéro à la première PR, ce qui est quand même l’objectif.

Bref, la doc pour le nouveau contributeur est largement améliorable, à mon avis. D’ailleurs, comment on s’y prend pour le faire ?

Salut firm1 !

tout d’abord, un immense merci pour ces stats de grandes qualité.

Il y a eu pas mal de réponses à ce topic alors je ne pourrais pas répondre message par message, je vais proposer une réponse globale, qui j’espère sera suffisament complète :

Le développement et son évolution

Le développement de zds a pas mal changé entre 2014 et 2018. Déjà au lieu de 1 projet (zds-site) + un projet annexe (python zmarkdown), on est passé à 4 projets :

• zds-site (python/django, js/CSS pour le front end)
• zmarkdown (JS)
• latex-template (latex)
• zds-ansible (la procédure de déploiement, via ansible)

Cela génère deux comportements différents qui n’apparaissent pas dans les statistiques de ce billet mais ce n’est pas grave :

• on a des contributeurs "à la volée" qui ne sont même pas francophone, notamment sur zmd et ses plugins
• on a des gens qui ne codent plus sur zds-site mais qui sont quand même contributeur quand même du projet technique zds.

Une autre nouveauté dans le développement, qui est apparu avec la v26 : nous sommes plus attentifs au contenu des commits (même si parfois on intègre des "typofix" dans le code, cela génère une déflation très forte du nombre de commits. Par exemple la zep 12 contenait 1000 commits, alors que les notificaitons, les tribunes, zmarkdown, les nouveaux epub/pdf, la publication partielle… ne doivent pas dépasser les 100 commits à eux tous ou alors de très peu)

Un aspect de la séparation des projets : nous publions plus rapidement les bugfixes. @sandhose a déployé une version intermédiaire en béta, je termine les tests demain et d’ici peu elle sera en prod.

Côté organisation, une feuille de route "gros grain" existe déjà https://github.com/zestedesavoir/zds-site/wiki/Feuille-de-route, notamment, on pourra remarquer que désormais les version "majeures" (celles qui méritent un chiffre et un nom) contiendront toujours 2 grosses fonctionnalités que la communauté aura choisi là ce sont les statisques pour les auteurs et l’ajout d’image via drag & drop pour la v28.

Le développement et sa communication

Bien que nous avons encore des choses à améliorer (par exemple un contact direct avec les auteurs lors des changements du markdown ou de l’interface de rédaction) nous avons quand même beaucoup amélioré la communication

• entre nous;
• avec le reste du monde.

Notamment, nous avons une série de billet nommée "Zeste Of Dev"¹², un certain nombre de live sur twitch (ça va revenir), de la communication sur les RS (merci les gens qui ont posté les tweet quand il fallait d’ailleurs) et sur les forums aussi bien la partie "développement", "bar à smoothie", "bug & suggestion".

Le développement et les développeurs

Le nombre de développeurs a effectivement diminué, ne nous cachons pas derrière notre petit doigts.

Il y a deux raisons à ça :

• Malgré quelques bugs, le site ronronne, la maintenance du code est donc assez légère
• Les humains ont une sacrée tendance à avoir une vie privée et des enfants, et à préférer ces derniers à des lignes de code.

Globalement nous avions historiquement une structure avec :

• un noyau de 6 ou 7 personnes
• un ensemble de personnes qui venaient aider en pointillé mais c’était dynamique avec 5/6 personnes de cet ensemble en permanance
• quelques personnnes qui corrigeait la faute d’orthotypo ou le bug qu’ils avaient trouvé et qui ne revenaient plus (et merci à eux en passant).

Le noyau s’est étalé:

• globalement ça fait pierre, situphen et moi sur zds-site
• pierre et karnaj sur latex-template
• victor sur zmarkdown
• sandhose partout

Pour les autres on retrouve des gens qui sont quand même proche de devenir le noyau du site:

• rezemika;
• nils;
• amarok.

AUxquels peuvent s’ajouter qwerty, abdelazer, gustavi, gcodeur, karnaj…

Je n’ai pas tous les noms car de mars à mai on a eu un gros problème :

• gcodeur a dû abandonner sa fonction de PM et me la donner par manque de présence
• j’ai ensuite eu ma propre période d’indisponibilité
• ensuite sandhose (le release master) a eu des problèmes perso et des exams ce qui a réduit sa disponibilité.

Sur 2018, pour la première fois de l’histoire de la technque sur zds, il ya eu une pause de 2 mois où on n’a rien fait ou presque.

Les choses vont revenir. Je suis déjà passé sur quelques PR avant mes vacances, puis c’est pierre qui a pris le relais. Des débugs devraient donc arriver sous peu.

ZDS et l’accueil des nouveaux

C’est difficile.

En soi, la documentation est complète. Elle est même à peu de choses près à jour (il me semble qu’on n’a pas bien expliqué pour zmarkdown).

Mais, comme dit plus haut, tout est basé sur l’idée qu’il faut avoir une connaissance de base sur

• comment on utilise git
• comment on contribue à un projet open source

Ensuite, on vous aide. Mais on n’a jamais réussi à faire venir des gens qui ont juste un peu de connaissance en développement ou même la simple envie d’apprendre (un comble pour un site qui s’appelle zeste de savoir et qui a pour moto "la connaissance pour tous et sans pépin").

On pourrait faire des efforts, mais je pense qu’on a tout simplement besoin d’aide. Là on est en plein dans le paradoxe de l’expert. Nous ne sommes pas intimidant car on ne veut pas les débutants mais parce qu’on n’est pas capable de se rendre accessible des débutants.

Si vous avez d’autres questions, je suis là.

Pour la doc, je suis assez ennuyé: jusqu’à un certain point, celle-ci ne peut pas expliquer comment fonctionne django, git ou github, ce qui est normal. Par ailleurs, toute tentative ayant en ce sens se solde d’ailleurs par un échec. Finalement, je trouve effectivement que la quasi-obligation d’une duplication entre le README et la doc propre de zds est une erreur, mais bon (bonne pratiques, toussa). Par contre, je suis preneur de toute amélioration de la lisibilité de la doc, qui passe de "installer zds et ces composants" à "voilà les doc des fonctions, débrouille toi". Là, y’a un peu de travail à faire

Quand à docker, plusieurs tentatives ont été faites, dont la dernière en date est ici. Moi, j’ai rien contre, mais force est de constater que le problème est plus compliqué qu’il n’y parait. Et comme tout bon projet libre qui se respecte, c’est pas l’envie qui manque, mais les connaissances. Si quelqu’un possède les connaissances, c’est avec plaisir qu’il existera une image docker et "qu’il-suffira-d’une-commande-pour-installer-ce-bazar". Tant que c’est pas le cas, ben on sais pas Je veux bien entendre que c’est un frein à l’intégration, mais je suis pas magicien

il me semble qu’on n’a pas bien expliqué pour zmarkdown

Je pense objectivement que non, parce que j’ai cherché.

J’ai de plus en plus l’impression que certains sont perdus s’ils n’ont pas leur petit Docker.

Je pense que oui, c’est devenu tellement la norme quand on contribue dans un projet de type "site" (qui nécessite un environnement spécifique, avec des données de qualif, etc.) que je fais partie des gens qui prennent peur quand on me demande de virtualiser un OS que je n’ai pas installé, parce que ouais, je vais pas installer le truc en dur sur ma machine… à chaque fois que je contribue, ou même pire, que j’essaie de regarder comment ça marche.

Donc c’est vrai que Docker rassure pas mal là-dessus. docker-compose up et le truc fonctionne, je peux jouer avec, je sais que je risque moins d’avoir de mauvaises surprises ou d’être obligé de demander au SAV sur IRC pourquoi sur ma version virtualisé de Debian x.y.z ça fonctionne pas.

Je trouve pas ça déconnant, du tout, que les gens soient perdus sans "leur petit docker". Je trouve au contraire que ça relève du respect du contributeur de leur filer "un petit docker".

EDIT : et oui, bien sûr c’est beaaaaaucoup plus facile à dire qu’à mettre en place. Je comprends très bien les dizaines de raisons qui vous empêchent de le faire aujourd’hui, malheureusement.

Après, je pense que ça serait déjà très bien si il y avait une commande simple qui installe tout. Ou deux pour satisfaire toutes les distribs.

Et on peut imaginer d’utiliser nvm pour la gestion de la version de nodejs

en soi, ça ne devrait pas être trop complexe de dockeriser. Pour l’instant on rattrape le retard qu’on a pris avant la sortie del a v27 puis on reprendra le boulot de dockerisation. @motet-a y avait bien avancé il me semble.

@amael c’est une solution proche de ce qu’on a aujourd’hui mine de rien ce que tu propose

Ben, un peu, mais c’est pas expliqué clairement, et, surtout, ce que je propose, c’est une solution qui fait tout en une commande. Sans séparation entre front, back et zmd. Et qui crèe le venv aussi.

En soi, l’idéal, pour ce qui est du python, ce serait d’utiliser pipenv.

Personnellement, pour installer zds-site sur ma machine, j’ai du

1. Installer les dépendances du back: make install-archlinux
2. Créer le venv: virtualenv zdsenv
3. Installer les dépendances du back: make install-back
4. Faire les migrations: make migrate
5. Installer nvm et l’utiliser pour installer node8
6. Modifier mon fichier de venv pour charger node8 lors de l’activation
7. Installer yarn
8. Installer les dépendances du front: make install-front
9. Construire le front: make build-front
10. Installer les dépendances de zmarkdown: make zmd-install

Je trouve que ça fait beaucoup.

Et ne dites pas qu’il fallait utiliser make install pour éviter un peu de ce bazar, il ne fait quasi rien et n’est pas bien documenté.

Je pense qu’il faudrait regrouper 1, 5 et 7 au sein de make install-<nom de la distrib> et le reste dans make virtualenv. (Ça peut s’appeler différemment, ce n’est qu’une proposition)

Je ne savais honnêtement pas que 6 était possible, et en ce qui concerne 5, j’ai déjà vu et testé beaucoup de trucs en 3 ans de dev' pour zds (nvm est passé à un moment), et tout ça me laisse l’impression d’un sacré bazar¹. Mais toute simplification est la bienvenue

Pour m’a part j’ai été un contributeur actif pendant une langue période et j’ai récemment voulu remettre les pieds dans le projet. J’essaye de faire un peu de QA à ma pause de midi mais voici les 2 points qui m’ont posé des difficultés pour me remettre au développement comme à l’époque :

• Un gros manque de temps. ZdS était le premier projet auquel je contribuais. J’étais étudiant avec peu de cours et beaucoup de temps libre. Ce n’est malheureusement plus le cas aujourd’hui.
• Un code de plus en plus complexe. Je connais assez bien le code pour avoir passer des heures à l’écrire et le relire mais des parties restent encore un peu obscures pour moi. Des morceaux sont assez complexes et je comprends que des débutants qui n’ont pas une grosse connaissance de Python ET Django aient du mal à contribuer.

Pour ma part je vais essayer d’intervenir sur des sujets précis et spécifiques que je maîtrise comme la sécurité ou l’optimisation de Django.

Autre remarque sur la décroissance du nombre de commits par année : il faut aussi se dire qu’en 2014 nous n’avions que peu de fonctionnalités. Aujourd’hui le site a une certaine stabilité et une grande partie (toutes ?) des fonctionnalités essentielles sont codées.

Et un OS, et les packets de cet OS qui vont bien. En fait l’idéal ce serait pas pipenv, ce serait plutôt un genre d’image contenant déjà tout ce qu’il faut et il suffirait de faire up et ZdS serait lancé en local.

Je crois qu’on est beaucoup à être d’accord avec cette vision.