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

a marqué ce sujet comme résolu.

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).
+0 -0

j’aimerais ajouter deux points à l’ODJ :

  • un qui à mon sens est obligatoire : les tickets "bloquants" ça ne prendra pas longtemps d’en parler mais je voudrais que ça soit dans le meeting
  • un qui peut être relégué dans la catégorie "si on a letemps" : la PR sur l’API des contenus.
+0 -0

Je rappelle les détails du prochain ZDS-Meeting :

  • Quand ? Le mardi 11 septembre (demain) à 20h (jusqu’à 21h30 ou 22h si on déborde)
  • Où ? Sur le serveur de Freenode, canal #zds-meeting

Je propose cet ordre du jour (très largement inspiré de vos idées) :

  • Changements de version

    • par quels moyens annoncer le contenu des versions mineures aux membres du site ?
    • comment garder une trace interne des versions et du résumé de leurs changements ? sur le Wiki de Github ?
  • PRs en attente car Work In Progress

    • le Work In Progress incarne-t-il le Bien ?
    • comment éviter que le Work In Progress tire en longueur ? comment aider les développeurs à achever leur travail/arriver à quelque chose de fonctionnel ?
    • à partir de quand et sur quels critères doit-on fermer une PR (qui peut être ré-ouverte plus tard mais risque de tomber dans l’oubli entre temps) ?
  • Mise en avant des PRs et des tickets

    • comment avoir une liste de PRs plus claire ? faut-il remplacer le [WIP] du titre par un tag WIP ? faut-il ajouter un tag QA Ready ? faut-il ajouter un tag QA ASAP pour prioriser la QA ?
    • comment prioriser le développement ? faut-il un tag Fonctionnalité majeure ?
    • faut-il reporter les tags du ticket (C-Front, S-BUG, etc) sur la PR (au risque d’avoir beaucoup de tags si on ajoute WIP, QA Ready ou QA ASAP) ?
  • zds-site à l’heure d’aujourd’hui

    • quels sont les tickets bloquants ?
    • où en est-on sur la PR de pierre-24 pour l’amélioration de l’installation et de la documentation ?
    • petit point sur la PR de l’API des contenus

Edit : Je me rend compte que ça fait pas mal de points et que ça risque de pas passer en 1h30–2h. Je ferais une estimation du temps de chaque point ce soir et j’enlèverai peut-être des morceaux si ça ne passe pas. :)

+1 -0

Je viens de recevoir un mail du directeur de mon école : J’ai une réunion "surprise" jusqu’à 19h mardi, donc je serai certainement en retard. (Voire absent)

Veuillez m’excuser.

+0 -0

Le deuxième ZDS-Meeting de cette série s’est déroulé hier soir comme prévu. Nous étions peu nombreux avec 5 membres, par contre nous avons réussi à faire une réunion de seulement 1h40 ! J’ai un peu modifié auparavant l’ordre du jour pour que l’on parle des tickets et PRs actuelles au début de la réunion et non pas à la fin. Vous pouvez lire la trace écrite ainsi que ce récapitulatif :

  1. Les PRs et les tickets actuellement

    • Tickets et PRs bloquants

      • L’API de Facebook n’est plus à jour

        • La question du maintien des inscriptions via les réseaux sociaux se pose. Un débat a eu lieu mais aucune décision n’a été prise car il n’y a pas eu de consensus, l’impact est important et on était trop peu nombreux.
        • La situation actuelle ne peut pas durer donc à moins que l’arrêt des inscriptions par réseaux sociaux et la migration des comptes actuels soient décidés très vite, il faut mettre à jour l’API car elle touche l’inscription et la connexion.
      • L’API des galeries est un pré-requis pour une fonctionnalité majeure (le drap’n’drop des images dans l’éditeur) : pierre-24 est en train de la développer
      • Le problème des notifications par courriel quand un membre inscrit via les réseaux sociaux n’a pas de courriel : c’est corrigé et sera mis en production en v27.3
    • Les PRs du moment

      • artragis travaille sur l’API des contenus (accès aux méta-données telles que le titre, la description, etc. + gestion de la rédaction en markdown) que l’on peut commencer à QA !
      • artragis propose aussi une PR pour améliorer les MPs suite aux validations des contenus : là encore on a besoin de QA et cette PR est prioritaire car elle améliorera le confort des auteurs et autrices !
      • pierre-24 a bien travaillé sur l’API des galeries et est en train de faire les dernières modifications après les retours de firm1, on est presque bon !
      • Eskimon a commencé sa PR sur les statistiques en janvier dernier (!) et bloque dans la dernière ligne droite sur les tests unitaires (il estime que c’est faisable mais que ça prendrait beaucoup de temps) mais la QA peut déjà commencer !
  2. Communication au sujet des changements lors des versions mineures

    • "Par quels moyens annoncer le contenu des versions mineures aux membres du site ?"
    • Un sujet sera créé sur le forum de la Dev' Zone et un nouveau message sera posté à chaque version mineure pour lister les modifications. Ça permet d’éviter de créer un nouveau billet à chaque version et les membres peuvent s’abonner pour recevoir des notifications.
  3. Le problème de la longue liste de PRs et des PRs en WIP

    • Nous avons actuellement 2 outils automatiques pour vérifier les PRs : Travis CI et Codacy. Codacy ne fonctionne pas bien et met donc certaines PRs en rouge alors qu’il ne devrait pas. On a décidé de le virer et de le remplacer par pylint et jshint que l’on intégrera dans Travis CI.
    • Il y a du nettoyage à faire dans les PRs, notamment fermer celles qui ne sont plus vraiment prises en charge et dont on n’a plus de nouvelles.
  4. La mise en avant des PRs et des tickets

    • (Ce point est dans la continuité du point précédent.)
    • On garde le [WIP] dans le titre quand tout n’est pas encore fini (mais cela ne veut pas dire qu’on ne peut pas commencer à QA). Toute PR qui n’est pas WIP est considérée comme pouvant passer la QA.
    • On va créer un tag "long term" pour les PRs qui vont être longues pour bien les séparer des PRs abandonnées.
    • Il faut utiliser le tag Zombie si on trouve qu’une PR est abandonnée, artragis tranchera si on garde la PR ouverte ou si on la ferme (c’est son rôle de Maintainer).
    • Le tag Bloquant pourra être utilisé (toujours avec parcimonie, mais plus fréquemment qu’actuellement) si on veut prioriser fortement une PR
    • On peut utiliser le tag Feedback si l’on veut avoir des retours (là encore c’est un tag peu utilisé actuellement)
    • Il faudra mettre à jour la documentation avec les modifications des tags et de leurs utilisations
    • On va probablement enlever la tag Évolution car tout ce qui n’est ni ni un Bug ni une Régression est une Évolution
    • Les tags du tickets (Bug, Régression, Front, Back, etc) sont reportés sur celui de la PR.
+2 -0

On va probablement enlever la tag Évolution car tout ce qui n’est ni ni un Bug ni une Régression est une Évolution

Deux avantages à conserver un tag même si c’est l’état par défaut :

  1. Ça permet de retrouver très facilement tous les tickets et PR concernés (il suffit de filtrer sur ce tag, au lieu de filtrer sur tout ce qui n’a pas tous les autres tags)
  2. Ça permet de savoir immédiatement si le ticket ou la PR a correctement été défini (s’il manque un tag et que Évolution est obligatoire, c’est que le tri n’a pas été fait ; si Évolution est facultatif, tu ne sais pas si c’est une Évolution ou si on a oublié de traiter le ticket)

Désolé, je n’ai pas encore mon emploi du temps pour les jours / semaines à venir, du coup je ne peux pas vraiment répondre… (En plus, je ne suis plus spécialement un membre actif…)

+0 -0

Je me permet de remonter ce sujet pour relancer la machine ! En ce moment on a d’un côté l’équipe technique qui est très (trop) réduite ce qui fragilise le projet, et de l’autre côté de potentiels nouveaux contributeurs intéressés par le projet mais freinés par la complexité de celui-ci. Le but de ce rendez-vous est donc faire connaissance, discuter, se synchroniser et se motiver ! Si vous êtes intéressés pour y participer, remplissez ce sondage avec vos disponibilités. Si on arrive pas à avoir tout le monde au même moment, on pourra en faire deux séparés.

Je me permets de mentionner des membres qui pourraient être intéressés et qui ne suivent pas forcément ce sujet : @Helmasaur @Amaury @Vanadiae @A-312 @TAlone @SylafrsOne @philippemilink

+2 -0

Je ne peux pas venir sur Paris en août.

EDIT : on me souffle que ce n’est pas en présentiel mais sur Discord, du coup pas de soucis.

+0 -0

Effectivement j’imagine ce rendez-vous comme les précédents, c’est-à-dire à distance et non pas en présentiel. J’aimerais bien qu’on essaie de faire ça en vocal sur Discord mais si ce n’est pas possible on peut très bien le faire par texte sur Discord ou avec un mélange des deux. :)

+3 -0

J’ai regardé le sondage et il n’y a pas vraiment une date qui sort du lot… On peut en tous cas écarter l’idée de l’organiser avant le 20 août. Si les étoiles s’alignent, l’idéal serait de l’organiser le lundi 26 août. En étant réaliste, on peut partir sur deux dates sur la période du 20 au 31 pour essayer d’avoir tout le monde.

+0 -0

Bonsoir tout le monde !

La réunion est en train de commencer donc n’hésitez pas à venir nous voir :)

Ordre du jour

  • Présentations

    • (Optionnel, on a le droit de garder un pseudonymat complet) Qui suis-je ?
    • Nouveau·elle contributeur·trice ? Ancien·ne contributeur·trice ? Curieux·se de passage ?
    • Qu’ai-je envie de faire dans les semaines/mois à venir ? À quel projet* ai-je envie de contribuer ? Quelles sont mes compétences actuelles ? Quelles compétences aimerais-je acquérir ?
  • Où en sommes-nous sur zds-site ?

    • PRs et tickets en cours importants [artragis]
    • la version 28.2 et la version 29 à venir [artragis]
    • vos questions
  • Comment rendre plus simple les premiers pas des nouveaux contributeurs ?

    • Une meilleure documentation
    • d’autres idées ?
  • tous les autres points/idées/questions

* Je me permets de rappeler la liste des projets :

  • zds-site pour le site en lui-même et les API (Python/Django + HTML/EPUB + CSS/SCSS + JS/Jquery/Gulp + un peu de bash/sh + les configurations avec ElasticSearch, Redis, MySQL…) [artragis est en charge]
  • zmarkdown pour le moteur de Mardown : conversion MD -> HTML et MD -> LaTeX (JS avec quelques dépendances sympas) [vhf (cepus, sur ZDS) est en charge]
  • latex-template pour le LaTeX des exports PDF [pierre-24 et Karnaj font le + gros du taf]
  • django-cors-middleware dépendance pour zds-site (Python/Django)
  • extensions-notificateurs pour les extensions Firefox et Chrome [AmarOk est en charge]
  • ansible-zestedesavoir configuration Ansible pour la mise en production [Sandhose + Situphen]
+0 -0

Bonjour à tous :D

Les personnes participantes lors de ce Zds meeting (26 août 2019 à 19h sur Discord) étaient : A-312 Amaury Artragis Situphen Philipmilink Gustavi Vanadiae sTAlone AmarOK (soit un total de neuf personnes !)

cf. mon VDD pour l’ordre du jour

Le compte-rendu

La version 28.2 est pas finie depuis longtemps Premier ménage fait pour éviter de rester trop longtemps, on arrive à la fin On va enlever la partie API tutos, pas le temps de replonger, trop longtemps dessus à faire des rebases, un peu compliqué trop à faire On est bien partis pour faire une vraie 28.2 en bêta @artragis aurait bien aimé le nouveau ZMD mais VHF (@cepus) n’a pas release donc on va quand même mettre en bêta pour diffuser 28.2 en septembre Donc il reste plus grand chose à faire (transcript) Pour la v29, deux grosses fonctionnalités : parcours et nouvelle interface de validation avec les suggestions

Validation : idée de @A-312 : pouvoir laisser des notes dans le contenu (au niveau de la partie ou du paragraphe) un peu comme Word pour éviter les MPs ultra longs, genre annotation, genre review sur GitHub

Parcours : pour l’instant on a tous une idée différente donc faudrait le spécifier pour s’ajuster Artragis a son idée à lui et on a pas envie de faire des tensions comme les tribunes au moment de la sortie, donc on va d’abord refaire un point sur la vision de chacun des parcours pour derrière faire un compte rendu et avoir une synthèse des idées pour aller sur quelque chose de bien défini (prise de décision, pas ajout de tout ce qui est dit, mais en prenant tout en compte ofc) Sinon y’a aussi la liste de lecture : Artragis la voit comme un truc qui se branche sur les parcours, fonction de son idée des parcours, par contre ça ne fait pas encore trop l’unanimité donc on va le mettre en feedbacks

Le reste c’est du bugfix et de l’amélioration, notamment deeeeeeeeee l’interface de validation, cf. sujet pour avoir des maquettes afin d’avoir un système plus simple, avec tout sauf l’éditeur pour ne pas se perdre, l’éditeur ce sera la version suivante. Jouer sur la sélection de licence et des demandes d’aides pour alléger les pages, par exemple sortir les demandes d’aide et les licences des pages principales pour les mettre à côté pour alléger le tout et ne les demander qu’à la mise en bêta / validation Avec pour les licences un wizard pour les CC et éventuellement autre chose pour les autres licences (genre tous drtois réservés mais en précisant, genre que c’est toutjours accessible gratuitement mais que la diffusion est polus restreinte) V30 : un éditeur à la codemirror, et pour les billets et les articles, un unique champ pour tout écrire vu qu’on a ps besoin de plus

@Amaury (merci pour tes pavés au passage ;) )

Centralisation de l’avancement des tâches -> https://github.com/zestedesavoir/zds-site/projects

Exercices (objectif v30 ?):

→ Des premières idées de développements progressifs pour les exercices, avec d’abord juste des QCM, puis ajouter des textes libres, puis des textes à trous…
→ Exercices uniquement côté client : on s’en fout de stocker (ou même donner) des notes, l’objectif est juste de s’auto-évaluer, pas de faire des MOOCS avec des certificats etc.
→ Première version des modules d’exercice (avec QCM) à proposer à la communauté pour la V30 (en demandant les fonctionnalités désirées par la communauté), puis en fonction de l’usage concret des exercices, améliorer petit à petit dans les versions ultérieures en ajoutant plus de types de questions ou autres.
+1 sur le plaisir d’installer ZdS Quand ça va pas j’installe ZdS depuis zéro et ça va mieux

  • zestedesavoir.com/forums/sujet/12901/suggestion-cocher-les-listes-depuis-laffichage/ ?

Attirance de ZdS aux nouveaux contributeurs :

@AmarOk => l’accompagnement / mentorat

Accueil des nouveaux

→ refaire la doc pour qu’elle devienne un point d’entrée vers toutes les ressources
→ la doc doit expliquer mieux comment contribuer, comment installer un environnement, contribuer, toucher à tel module, etc.

@Situphen a commencé ça :

J'avais commencé une structure il y a de ça quelques mois (il faudrait que je me replonge dedans) :

- Présentation du Projet ZDS
      - Notre projet principal, zds-site
      - Aperçu des projets de secondaires
- [Tutoriel] Je fais mes premiers pas
      - Récupérer le code source (cloner le dépôt, clés SSH, git clone...)
      - Installer le projet rapidement (commandes make install-*)
      - Préparer le terrain (mettre à jour les dépendances, python manage.py migrate, builder le front, créer des fixtures)
      - Lancer le site web (lancer zmarkdown, lancer le serveur)
- [Tutoriel] J'explore un peu plus en profondeur
      - Utiliser la recherche (lancer ElasticSearch, indexation des contenus)
      - Générer PDFs et EPUB
      - Autres commandes du manage.py (nettoyage des alertes et notifications, générer rapports de release...)
- [Tutoriel] Je fais ma première contribution (tests unitaires, Travis CI...)
      - Fonctionnement du projet (code de bonne conduite, workflow général, utilisation des tickets et PRs)
      - Proposer une nouvelle fonctionnalité ou une correction de bug
      - Vérifier une proposition de code source d'un autre contributeur
 - Installation et utilisation avancée
      - Installation détaillée sous Linux
      - Installation sous Windows (obsolète)
      - Installation sous MacOS (obsolète)
      - Installation du frontend
     - Installation de zmarkdown
      - Installation de ElasticSearch
      - Installation de LaTeX et de latex-template
      - Configuration des serveurs de production
Backend
Doc technique du backend
Frontend
API
Autres outils

→ améliorer l’installation sous Windows
→ docker why not mais pas une priorité et attention à la maintenance
→ améliorer le README pour qu’il soit plus clair sur comment contribuer et qu’est-ce qu’est ce projet
→ étiqueter les tickers avec good first issue ou équivalent, contacter GH pour que la page https://github.com/zestedesavoir/zds-site/contribute liste les bonnes (et pas C-Docs :D), et mettre cette page en avant dans la doc (cf. tickets "Facile")
→ mettre en avant sur le site : le dépôt, la doc, Discord; afin qu’on puisse plus facilement trouver le moyen de contribuer

Bonus

Deux autres sujet par @gustavi

  1. Il a un bon plan pour profiter d’une offre gratuite sur une solution qui fait de l’analyse SEO un peu poussée, il reviendra en parler dans les semaines qui arrivent avec plus de détails. → à voir si ça nous intéresse, ça sort des stats qui peuvent être intéressantes Ça peut ne rien sortir comme sortir 1 milliard de choses et on pourrait s’en servir pour améliorer les points où c’est utile Il en parle et nous tient au courant sur les jours/semaines qui arrivent

  2. Coût de l’infra : points à discuter avec le @CA (je ping @nohar et tout le @CA (peut-on faire ça d’ailleurs ?), en privé (rien d’extraordinaire juste pour pas encombrer la réunion)

Zmd

  • hl_lines
  • line_nostart

@sTAlone :

graph TB
A((round)) --> B(Rounded)
B --> C[Square]
C --> D{Diamond}
C --> E>Strange]

@Amaury a proposé de regarder du côté de cet outil https://github.com/Khan/tota11y

Proposez des modifications du compte-rendu si jamais j’ai oublié quelque chose

Zestement et à un prochain zds meeting ! ;)

+3 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

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