Licence CC BY

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

La plateforme technique de ZdS est-elle intéressante pour les développeurs ? pour les hébergeur ?

Dernière mise à jour :
Auteur :
Catégorie :
Temps de lecture estimé : 16 minutes

Après une étude de l’attractivité de Zeste de Savoir du coté des auteurs de contenus (ici et ), je suis de retour pour étudier cette fois-ci l’attractivité de la plateforme technique de Zeste de Savoir.

Vous le savez certainement, la plateforme technique de ZdS est gérée par une équipe dont le rôle est de mettre en place des solutions techniques attendues par la communauté de Zeste de Savoir.

Aujourd’hui ce qui va nous intéresser, c’est de savoir si le code source du site attire du monde (devs back, devs front, admin sys, testeurs, etc.). On ne cherchera donc pas à savoir s’il "peut" attirer du monde, mais s’il attire réellement. On reste donc dans les faits.

Les contributeurs au code source

Le langage de développement principal de la plateforme ZdS est le langage python. Il constitue ~69.6% des lignes de code de dépôt zds-site. Il apparaît donc évident que pour développer pour ZdS en tant que développeur back-end, il faut savoir utiliser python (et le framework Django).

Ce langage a été choisi à l’origine pour sa simplicité et l’objectif a toujours été de faciliter l’arrivée de nouveaux contributeurs dans le projet, afin d’en faire non seulement un projet opensource, mais aussi communautaire. Nous allons essayez de savoir si ces attentes ont été satisfaites.

Parmi les contributeurs, on constate que depuis le début de l’histoire de ZdS, 31 contributeurs se sont impliqués un minimum 1 dans le développement de ZdS.

Contributeurs
Contributeurs

Voici un histogramme qui montre le nombre de contributeurs sur le dépôt git de Zeste de Savoir par année, et par mois. On comptabilise ici tous ceux qui ont fait un commit dans la période sélectionnée.

Nombre de contributeurs
Nombre de contributeurs par année
Nombre de contributeurs par année
Nombre de contributeurs par mois
Nombre de contributeurs par mois

On remarque plusieurs choses ici :

Conclusion

On constate donc, que le code du site attire un peu moins qu’avant. ça s’explique au moins par deux choses :

  • au début les besoins étaient nombreux, vu le nombre de demandes de la communauté
  • aujourd’hui, le dépôt principal n’est plus zds-site, le développement est devenu très actif sur zmarkdown

Au moment de la rédaction de ce billet, les 10 plus gros3 contributeurs à la plateforme sont les suivants :

membre nombre de commits
@firm1 878
@artragis 822
@Alex-D 704
@pierre-24 440
@Eskimon 287
@sandhose 273
@SpaceFox 233
@gustavi 216
@Situphen 216
@Andr0 193

  1. On va considérer qu’au delà de 10 commits sur le dépôt principal, vous avez été impliqué.

  2. Le code source a commencé a être développé en novembre 2013, donc l’année 2013 n’était pas une année pleine.

La productivité des contributeurs

Avoir beaucoup de contributeurs c’est bien, mais des contributeurs qui produisent c’est encore mieux.

Ci-dessous un histogramme qui représente le nombre de commits par an sur le dépôt zds-site.

Nombre de commits par année
Nombre de commits par année
Conclusion

On constate une grosse baisse de productivité entre 2015 et 2016.

Le turn over des nouveaux contributeurs

Une question qui me taraudait pendant cette étude, était de savoir quand est-ce qu’arrivent de nouveaux contributeurs ? Combien sont attirés par le développement du site ? Est-ce que cet effectif reste stable ? Et surtout, quand et pourquoi décident-il de partir ?

Partir ou rester ? Telle est la question ...
Partir ou rester ? Telle est la question ...

Les histogrammes ci-dessous représentent le nombre de contributeurs qui arrivent (en bleu) par mois ou par année et le nombre de contributeurs qui partent (en orange) par mois ou par année.

Turn over des contributeurs
Entrée/Sortie des contributeurs par an
Entrée/Sortie des contributeurs par an
Entrée/Sortie des contributeurs par Mois
Entrée/Sortie des contributeurs par Mois
Détecter le départ d’un contributeur

Comment tu sais qu’un contributeur est parti ?

Il suffit d’identifier à quel moment un contributeur arrête de committer sur le dépôt.

Ce qu’on peut retenir

En observant bien les choses, on peut en conclure que :

  • Depuis 2016, on perd plus de contributeurs qu’on en gagne. Heureusement que l’année 2014 nous a ramené beaucoup de nouveaux contributeurs
  • Les nouveaux contributeurs provenant de l’ouverture du site n’ont pas pu être fidélisés, ils n’ont pas pu être convertis en contributeurs réguliers.
  • Depuis décembre 2017, les nouveaux contributeurs se font très rares.

Quel est le comportement adopté par les nouveaux contributeurs ?

Dans le développement logiciel, on distingue précisément deux catégories de ticket :

  • Les correctifs de bug : une tache que l’on pourrait qualifier d’ingrate, car on corrige des problèmes qui viennent du code écrit par quelqu’un d’autre.
  • Les ajouts de fonctionnalités : rajouter des nouvelles choses dans le code a très souvent un impact directement visible auprès des utilisateurs
Bug or feature ?
Bug or feature ?

Dans cette étude, j’ai essayé de comprendre, dans quelle catégorie rentre les nouveaux contributeurs. Autrement dit, on va s’intéresser aux premiers commits que fait un contributeur quand il arrive. On va donc calculer la différence entre les lignes ajoutées et les lignes supprimées par un contributeur pour savoir si les contributeurs sont attirés par la correction de bugs ou par l’ajout de fonctionnalité.

Les hypothèses sur lesquelles je me base sont loin d’être les plus intéressantes, mais par souci de simplicité, on va considérer que si un contributeur dans le mois, fait plus d’ajout de lignes que de suppression, et que la différence de lignes est supérieure au nombre de lignes supprimées, il s’agit d’une nouvelle fonctionnalité. Sinon, on parlera de correction de bug ou de refactoring.

Partant de là, on obtient le camembert suivant qui représente la répartition des membres qui rentre sur le projet.

Par quoi sont attirés les nouveaux contributeurs ?
Répartition Bug ou Feature ?
Répartition Bug ou Feature ?

Comme on peut l’observer, les nouveaux contributeurs commencent principalement par de la correction de bug ou encore du refactoring.

La fidélisation des contributeurs

Un contributeur fidèle est un contributeur qui, lorsqu’il commence à contribuer, continue pendant un bon moment. Je me suis donc intéressé à la durée de contribution sur zds-site.

Fidélité
Fidélité

On obtient l’histogramme suivant qui montre, pour chaque contributeur, la durée (en nombre de mois) entre son premier et son dernier commit.

Durée des contributions
Durée des contributions
Conclusion

On constate que :

  • Le tiers des contributeurs ne contribuent que ponctuellement (une journée)
  • Il y a tout de même un gros vivier de contributeurs qui se sont investis longtemps sur le projet. C’est donc autant de membres qui connaissent plus ou moins bien le code de Zeste de Savoir.

Il faudrait sonder les contributeurs pour essayer de savoir pourquoi ils ont arrêtés les contributions.

La plateforme intéresse t-elle les hébergeurs ? pourquoi ?

Il y en a qui sont déjà allé plus loin qu’une simple déclaration d’intention en installant la plateforme ZdS pour une utilisation personnelle.

DansTonCube

Il s’agit d'un vieux fork (il date de 2015) du code source du projet zds-site. L’idée était de faire vivre une communauté Minecraft en leur proposant au travers de zds-site des outils communautaire (forums, espace de rédaction, etc.). Le fork avait été réalisé par un membre de l’équipe technique à l’époque @gustavi.

Malheureusement ce projet est mort suite à un manque de motivation dans leurs équipe. Cependant les retours d’expérience sont toujours intéressants. Les problèmes qui avaient été relevés à l’époque pouvaient être regroupé dans les catégories suivantes:

  • Flexibilité du front : la variabilisation et l’organisation a été revue depuis, ça reste perfectible, mais l’équipe technique a fait un gros travail dessus
  • La documentation : elle a été améliorée depuis le temps. Cependant, la documentation du front reste toujours problématique puisqu’elle est toujours inexistante.

Bref, c’était le premier vrai fork de la plateforme technique.

Une tentative de ZdS en Kirundi ?

Le code source du site est pensé pour être utilisé dans une autre langue que le Français. C’est ainsi qu’un membre de Zeste de Savoir s’est renseigné dans l’objectif de déployé la plateforme technique pour l’utiliser dans sa langue maternelle le Kirundi. Cette histoire date de 2017.

La tentative semble avoir échouée suite à un double problème de compétence de l’hébergeur ainsi qu’un problème de documentation du coté de ZdS.

Conclusion

On constate donc qu’aujourd’hui le code source du site est surtout utilisé par l’association Zeste de Savoir. Peut-être qu’un jour le projet sera utilisé sérieusement ailleurs, mais ce n’est pas encore le cas.


Voilà, c’est tout pour cette étude. On pourrait encore creuser plus (quel est le background des contributeurs ? Comment en sont-il arrivés à contribuer ? Qu’est-ce qui les attirent ?), mais je préfère m’arrêter là pour le moment.

On a pu, en analysant principalement le dépôt git du site, constater un certain nombre de choses. On pourrait s’appuyer dessus pour améliorer l’attractivité de la technique de Zeste de Savoir.

Questions à la communauté

Et vous, qu’est-ce qui vous a motivé au départ à contribuer à la technique de Zeste de Savoir ? Et pourquoi avez-vous abandonné ? Pour ceux qui n’ont jamais tenté l’expérience, qu’est-ce qui fait que vous ne vous êtes jamais lancé ?

Merci à tous de m’avoir lu.

25 commentaires

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.

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+2 -0

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 ?

Édité par lthms

Merida is so cool · “Now that I have built my very own hammer, nothing looks like a nail anymore. ”

+6 -0

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 ?

"Les accidents dans un système doivent se produire, mais il n’est pas obligatoire qu’ils produisent pour vous et moi." Laurence Gonzales - Deep Survival

+0 -0

@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 ?).

Édité par A-312

✈️ // 🐺 Ami des loups // 🎮 Coding Game // 🐤 Twitter @A312_zds // :B // L’hiver vient // @**A-312** pour me ping

+0 -0

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. :P

Hier, dans le parc, j’ai vu une petite vieille entourée de dinosaures aviens. Je donne pas cher de sa peau.

+0 -0

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.

HTTP/1.1 418 I’m a teapot

+1 -0

Quand je vois la documentation pour installer l’environnement, cela me semble être le parcours du combattant.

EtienneR

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 !

+0 -0

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 !

+2 -0

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

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+4 -0

~~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.

Édité par 5IM0N

+0 -0

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. (https://zestedesavoir.com/forums/sujet/10829/planifier-une-publication/#p181763).

pierre_24

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.

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 ?

lthms

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.

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

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 sèche un peu pour le Tweet que j’ai prévu demain, quelqu’un a une suggestion ?).

A-312

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

Quand je vois la documentation pour installer l’environnement, cela me semble être le parcours du combattant.

EtienneR

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.

SpaceFox

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.

+0 -0

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 ^^

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+7 -0

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 ? :D

+5 -0

Équipe technique

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"12, 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à.


  1. https://zestedesavoir.com/billets/2457/chronique-zest-of-dev-6/ pour le dernier bilet

  2. Oui @blackline, je pense à toi, je te PM demain, puisque je vais écrire un nouveau billet zest of dev sous peu.

Édité par cepus

+7 -0

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 :magicien:

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

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

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+1 -0

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.

Édité par Javier

Happiness is a warm puppy

+6 -0

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.

On pourrait faire quelque-chose comme
  • Installez les dépendances logicielles avec make install-<nom de la distrib>
  • Installez l’environnement virtuel avec make virtualenv
    Ceci installe les dépendances python du backend, fait les migrations, installe le front et installe zmd.

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

+3 -0

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

Édité par artragis

+0 -0

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)

+6 -0

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é bazar1. Mais toute simplification est la bienvenue :)


  1. Pourquoi le programme d’installation ce permet de modifier le package.json, sans déconner ?

Édité par pierre_24

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+2 -0

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.

"I think that it’s extraordinarily important that we in computer science keep fun in computing." — Alan J. Perlis

+4 -0

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.

amael

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.

Vous aimez le frontend ? Il y a un tas de petites tâches faciles si vous voulez contribuer à ZdS : https://github.com/zestedesavoir/zds-site/issues?q=is%3Aissue+is%3Aopen+label%3AC-Front

+5 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte