Réunion des dév' de Zeste de Savoir

Salut les zesteurs et zesteuses,

Ça fait quelques temps que l’on n’a pas fait de ZDS-Meeting et je propose que l’on relance ces rendez-vous ! J’ai été moins impliqué ces derniers temps dans le développement du site, mais j’aimerais reprendre le rythme pour contribuer un minimum régulièrement. J’ai l’impression qu’il y a un regain d’intérêt ces derniers temps, avec notamment le billet de firm1 ou encore le nettoyage de pierre-24 sur Github. Il y a aussi de nouvelles têtes sur Github que je ne connais pas assez J’avoue que j’ai un peu perdu la vision d’ensemble que j’avais (notamment concernant zmarkdown, latex-template et leur intégration à zds-site) et j’aimerais y remédier.

Je propose donc de profiter du regain d’énergie qu’il y a, pour organiser un ZDS-Meeting ! Je propose que ces quelques points soient abordés :

• comment le projet ZDS est découpé : zds-site, zmarkdown et latex-template principalement (ainsi que les extensions web et zds-ansible si ça intéresse certains)
• un petit tour de présentation des contributeurs (potentiels y compris) du projet : quels sont les compétences actuelles et visées de chacun ? sur quelle partie du code chacun veut travailler ? est-ce que certains contributeurs veulent de l’aide pour se lancer ?
• parler de l’itération des versions pour zds-site, notamment sur le choix récent de 1 version contient 2 fonctionnalités majeures demandées par la communauté (il ne s’agit pas de remettre ça en question, mais que tout le monde soit au courant et de décider de comment on arrive à cette objectif)
• parler des modifications à apporter à la documentation du projet
• parler du développement en lui mēme : quelles PRs à merger rapidement ? à débloquer ? quels tickets bloquants ou sur lesquels discuter ? etc

Qu’est-ce que vous en pensez ?

Je propose que le ZDS-Meeting soit vocal, mais c’est à voir en fonction notamment du nombre de participants. J’aimerais que l’on inscrive les ZDS-Meeting dans la durée, à voir tous les combiens (semaine ? mois ?).

Zestement,
Situphen

Édition : Modification de l’ancien titre « ZDS-Meeting le reborn² » par l’actuel

ça m’a donné envie aussi de me remotiver un peu.

Par contre le meeting en vocal e ne pourrais pas, j’ai des avions qui font des bruits immenses chez moi ( @nohar pourra vous le confirmer ) et mon micro n’est pas top.

+1 pour inscrire ça dans la durée.

Alors … Oui, déjà. Par contre, un autre argument pour l’écrit, c’est que ça laisse des traces plus facilement lisibles (on s’amusait toujours à poster la conversation, à l’époque), donc faudrait un secrétaire le cas échéant. Comme vous voulez

Je propose comme ça car dès la première lecture du message de Situphen, je me suis posé la question.

Un gitter ? Si vous avez un compte github, vous pouvez vous y connecter. C’est par écrit et il y a moyen de recevoir des emails quand il y a de nouvelles conversations. C’est comme ça que fonctionne l’équipe technique de remark, le parser markdown derrière zMarkdown. Sinon, un framatalk, un salon discord, une liste de discution par email ou un gros MP, les solutions ne manques pas vraiment mais certaines me semblent plus adaptées que d’autres.

gitter est assez cool, oui et permettrait de remplacer irc mais bon ça veut dire encore un compte à créer et encore plus de dépendances à github.

La question que je me pose, c’est quand est-ce le meilleur moment ?

C’est la periode des vacances alors :

1. Certains ont plus de temps
2. D’autres partent en vacances (moi \o/).

Alors, c’est a la fois le bon moment et le mauvais

Mais vocal ou pas, je me joindrais a vous (apres le 7 Sept)

Je ne sais pas trop quel est le meilleur moment, mais en tous cas on arrivera pas à avoir toujours tout le monde de présent. Dans la mesure du possible et pour garder les ZDS-Meeting assez réguliers dans la durée, il faudra que l’absence de certains membres ne soit pas bloquante.

C’est clair qu’on ne trouvera jamais de "meilleur moment" qui satisfasse tout le monde.

Un bon compromis je pense serait d’en faire un toutes les deux semaines. ça permet de faire des meetings courts (dans ma tête je ne me vois pas aller au delà d’1h30) et ça permet aussi à celui qui est absent à un meeting de ne pas trop attendre pour le prochain.

Oyé oyé Oyez oyez,

Je propose que l’on fasse un premier ZDS-Meeting la semaine du 20 août. Je ne sais pas combien de personnes seront disponibles cette semaine là, ni sur quels créneaux horaires, mais on va le savoir grâce à ce beau petit sondage ! Si vous ne pouvez pas venir soyez rassurés, ce n’est que le premier et d’autres suivront je l’espère

*Oyez. Impératif du verbe « ouïr », ~synonyme de « écoutez ».

Fin de la parenthèse culturelle, vous pouvez reprendre une activité normale.

Le mardi 21 aout à 20h semble être un bon créneau.

On bloque la date ?

Re,

Le 21 c’est déjà demain.

On a évoqué beaucoup de canaux, mais on en a choisit aucun. Finalement on fait ça ou ?

Discord me semble convenir, mais si quelqun veut absolument pas l’utiliser qu’il propose qqch d’autre et on choisira

Perso, l’outil importe peu pour moi (tant qu’on peut y taper du texte).

C’est demain et on a pas eu le temps de discuter des différents outils donc je propose que l’on reste avec IRC pour ce ZDS-Meeting.

Rendez-vous donc mardi 21 août (demain) à 20h sur le canal #zds-meeting de Freenode ! Je préfère qu’on évite #zds-dev car sinon les bots de Github et Travis CI risquent de polluer notre conversation. Pour les utilisateurs de Matrix, le salon est #freenode_#zds-meeting:matrix.org.

Comme prévu, hier a eu lieu le premier ZDS-Meeting depuis le récent regain d’intérêt pour le développement de ZDS. Celui-ci a duré 2h15 environ (ce qui est plus que les 1h30 voulues par firm1, mais on fera mieux la prochaine fois) et 9 membres y ont participé ! L’ordre du jour était le suivant :

1. Petite présentation de chacun : Qui es-tu ? Quels sont tes compétences actuelles et celles que tu vises ? Sur quelle partie du code tu as travaillé et tu veux travailler ? SI tu es un nouveau contributeur, veux-tu de l’aide ?
2. Comment est découpé le projet ZDS (zds-site, zmarkdown, latex-template et ansible-zestedesavoir) ?
3. Itération des versions de zds-site : comment s’organiser pour le développement des deux fonctionnalités principales pour chaque version majeure ?
4. Modification de la documentation pour la rendre plus accessible aux nouveaux contributeurs
5. zds-site en ce moment : quelles PRs à merger rapidement ? à débloquer ? quels tickets bloquants ou sur lesquels discuter ?

Qu’est-ce que nous à appris ce ZDS-Meeting ? Quels débats ont eu lieu ? Quels décisions ont été prises ? Si vous avez la flemme de lire la trace écrite, voici un petit compte-rendu !

1. Présentation de chacun

   • Sans trop de surprise, au moins 6 contributeurs sur les 9 présents sont encore en étude, principalement en informatique mais pas que !
   • Parmi les 9 présents, 7 sont des anciens contributeurs et 2 des (relativement) nouveaux contributeurs

2. Comment est découpé le projet ZDS ?

   • zds-site, la base du code de ce site web
   • zmarkdown (qui remplace python-zmarkdown), pour transformer le markdown en html et en latex
   • latex-template, pour faire des beaux PDFs grâce au latex généré par zmarkdown (et dont l’installation n’a pas l’air d’être trivial)
   • documents-association et documents-communication, pour garder bien au sec les documents importants

3. Itération des versions de zds-site

   • On va différentier les versions mineures (17.1, 17.2, etc) des versions majeures (17, 18, etc). Notre discussion a rejoint ce qui a été proposé par artragis dans sa chronique Zest of dev 7
   • Les versions mineures sont réservés aux corrections de bugs et aux petites fonctionnalités. Dès qu’il y a une certaine quantité de petits changements, une nouvelle version mineure passera en bêta quelques temps puis elle sera déployée en production. Normalement ces versions sont légères et seront mises en production assez régulièrement.
   • Les versions majeures embarqueront les grosses fonctionnalités demandées par la communauté (suivant cette feuille de route). Elles seront probablement plus grosses (+ de lignes de code modifiées) et peuvent entrainer plus facilement des régressions, donc elles seront en bêta plus longtemps. Leur développement ne doit pas bloquer le développement des versions mineures donc il se fera en parallèle et il faudra voir comment bien distinguer les deux.
   • Qui dit mise en bêta/production dit infrastructure, la discussion s’est donc déportée sur ce sujet. Et c’est Sandhose qui travaille encore et toujours à l’amélioration de l’infrastructure des serveurs ! (Je ne suis pas spécialiste donc corrigez moi si j’ai mal compris.) Un des objectifs est l’automatisation, pour pouvoir déployer plus fréquement et avec moins de pépins. (Peut-être même verra-t-on un jour la bêta se mettre à jour dès qu’une PR est acceptée sur zds-site…) Sandhose a parlé de centralisation du monitoring de la production et de la bêta si elle est rappatriée sur ses serveurs. (Et peut-être même qu’il y aura un jour plusieurs bêtas…)

4. Rendre plus accessible la documentation aux nouveaux contributeurs

   • Une triste véritée est que même les contributeurs vétérans trébuchent lors de l’installation du projet !
   • pierre-24 s’est donc mis au travail pour mettre à plat et simplifier l’installation du projet (voir sa PR sur Github)
   • firm1 travaille sur Docker (voir sa PR sur Github qui reprend un précédent essai de motet-a)
   • En dehors de l’installation, il faut travailler sur la documentation en elle-même ! La documentation doit être celle du projet ZDS et ne pas se cantonner à zds-site ; elle doit inclure une présentation du projet ZDS et des sous-parties zds-site, zmarkdown, latex-template… On s’est mis d’accord pour rappatrier le contenu CONTRIBUTING.md dans la documentation pour éviter les bouts de documentation par-ci par-là.

5. zds-site en ce moment

   • On a 3 gros chantier : la modification de la documentation et de l’installation ; les statistiques pour les contenus ; le drag’n’drop pour les images.
   • artragis rappelle qu’il faut penser à faire de la QA

Merci à tous ceux qui étaient présents hier soir et on se donne rendez-vous dans quelques semaines pour un autre ZDS-Meeting !

Comme promis, j’ai mis à jour la feuille de route pour donner plus de visibilité https://github.com/zestedesavoir/zds-site/wiki/Feuille-de-route

n’hésitez pas à faire vos retours.

ça va déjà faire presque 2 semaines depuis le précédent. Peut-être qu’il serait temps d’en relancer un non ?

@firm1 merci d’avoir relancé le sujet

J’ai fait un petit sondage, le même que la dernière fois mais en enlevant les créneaux 14h-16h et 16h-18h en semaine (au fur et à mesure j’essaie de peaufiner le sondage) !

N’hésitez pas à donner des idées pour l’ordre du jour ! Est-ce qu’il y a une chose en particulier dont vous voulez discuter ? Ça peut être un point à aborder que vous trouvez important, ou simplement une question que vous avez en tête et pour laquelle vous souhaitez plusieurs réponses/avis.

N’hésitez pas à donner des idées pour l’ordre du jour

• Une question que je me suis posé dernièrement, c’est "Qu’est-ce qui a changé entre la version 27.1 et la version 27.2". Je pense que je ne suis pas le seul, et ça serait pas mal qu’on parle un peu de comment on communique nos changements aux membres du site.
• Il y’a pas mal de PR sur le dépot. Quand on regarde de plus près, on se rend compte qu’il y’en a pas mal qui sont surtout des WIP et donc qu’on ne peut pas QA ni merger en l’état. Un projet avec autant de PR en attentes ne donne pas une bonne image pour un nouvel arrivant, je ne sais pas si on peut trouver des solutions pour ça, mais on peut en parler vite fait ?
• Qu’est-ce qui manque pour merger la doc de pierre_24 au plus vite ? ça aiderait vraiment beaucoup j’ai l’impression, car actuellement c’est un peu le bordayle.

Ce sont les questions qui me viennent en tête comme ça.

On peut en discuter, mais le [WIP] est quelque chose qui moi ne me dérange pas, parce qu’elle permet d’avoir des retours et de voir que quelqu’un travaille sur la chose. Ce qui est plus "triste", c’est les WIP qui tirent en longueur (et j’en veux absolument pas aux développeurs, c’est dur de tenir la longueur, surtout quand on ne sais pas de quoi son emploi du temps sera fait).

Pour moi, la discution sur ce point devrai au moins servir à éclaircir 3 choses:

1. Est ce que vous êtes d’accord avec cette vision du "le WIP c’est bien" ? Et si oui, est ce que à la place de [WIP], est ce qu’on ne mettrait pas un tag dédié ?
2. À partir de quand est ce qu’on considère qu’une PR est trop vieille ? (pas une question facile)
3. Comment indiquer efficacement quand la QA peut être faite (elle peux très bien se passer au fur et à mesure, comme tu l’a fait pour moi, @firm1 ou à la fin, et les deux dépendent fortement de la PR).