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:
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é ?
À partir de quand est ce qu’on considère qu’une PR est trop vieille ? (pas une question facile)
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).
D’après le sondage le meilleur créneau pour le prochain ZDS Meeting est le mardi 11 septembre de 20h à 22h,soit dans 4 jours ! Merci @firm1 et @pierre_24 pour vos idées, si d’autres membres en ont moi je dis "Allez-y c’est le moment"
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.
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)
Je sais pas encore si je serais présent (et si oui ce sera en retard), mais si a l’occasion vous pouvez parler de la PR-bientot-plus-WIP sur les stats (notamment les TU) ça serait chouette
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 :
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 !
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.
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.
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.
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 :
Ç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)
Ç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…)
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.
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.
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.
Les étoiles ont l’air de s’aligner donc je pose la date du prochain ZDS Meeting au lundi 26 août à 19h sur Discord dans les salons textuel #zds-dev et vocal ZDS Dev !
Ce ZDS Meeting m’a motivé à enfin me mettre à Discord ! Puisque je l’ai un peu cherché, je mets ici le lien d’invitation Discord, ça peut peut-être servir à d’autres.
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]
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 !)
→ 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
→ 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.
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
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
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)
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