Bon, avant de mettre des coups de sabot je vais faire le point
Voici une compilation des choses les plus utiles que je racontait jusque la par MP… (c'est pourquoi vous verrez des formulations "tu" entre autres). Pardonnez les repetitions et autres formules bizarre, c'est du mix de MP que j'ai un peu copier/coller brutalement pour m'eviter de refaire une enieme fois le meme topo Vous avez le droit a tout en une seule fois, sans suspens, sympa non ?
Communication
Primo, il existe trois vecteurs de communication pour papoter sur le dev'. Ils sont tries par ordre de "vitesse de réponse" et donc a privilégier dans cet ordre :
- IRC (je suis tout le temps sur #zestedesavoir et de temps en temps sur #zds-dev)
- Le bar-back
- Ma boite a MP
Je vais le répéter mais ca mange pas de main : Aucun dev' ne mord. Si vous avez une question n'ayez pas peur de la poser en publique (forum/IRC), les membres de ZdS sont d'une patience et d'une pédagogie rare, profitez-en ! J'ai moi-meme fait mon boulet au debut du site (et vazi que je te balance des commits direct sur master sans PR ) mais personne ne m'en a voulu et rien n'a ete casse, et du coup j'ai appris des choses.
La vie du code
Voici grosso-modo un petit résumé du cycle de vie du code et des différents postes ou n'importe qui peut agir :
- Les discussions : Que se soit sur le fofo dev' ou sur GitHub, il y a plein de choses à discuter, décider, trancher. Tout fonctionne en démocratie, tout le monde à le droit d'avoir son mot à dire. Pour le developpement, le dernier mot revient cependant à SpaceFox qui est un peu le "responsable technique", surtout là pour trancher quand un consensus ne veut pas se faire (cas assez rare). Il y a en ce moment plusieurs discussions actives :
- La ZEP-23 sur l'API pour les MP (qui fait suite à la ZEP-17, j'y reviendrais). Elle est gérée surtout par Andr0. Il a besoin de retour et d'avis sur la specification de l'ensemble, si tu as des connaissances dans le sujet n'hésites pas ! ;
- La ZEP-12 sur la refonte des tutos/articles est aussi un point important. Les discussions sont deja tres avances et du dev' est commencé. Si c'est un sujet qui t'intéresse tu peux en parler plus en détail avec gustavi et pierre-24 qui s'occupent de cette dernière.
- D'autres sujets intéressants que je te laisse découvrir
- Le bugtracker : C'est github qui est utilisé pour le moment. Tu y trouveras tout les tickets de bugs ou d’évolution. Ici c'est du bénévolat, donc si un ticket t’intéresse, prends le ! en général cependant on essai de les traiter avec les priorités suivantes :
- Les Pull-Requests : Avant que le code ne parte en prod', les corrections apportées par les membres sont testé unitairement par d'autres membres. On appelle ca la QA. Tout le monde est invité à en faire. C'est pas le plus drôle mais c'est indispensable et c'est une très bonne étape pour ce familiariser avec les outils. J'avais fait un petit guide à ce sujet ;
- Les tests en vrai, lors des releases, sur le site beta.zestedesavoir.com ;
Bref, il y a de quoi s'occuper pas mal dans la vie du site !
Organisation du code
Je vais parler vite fait du front car ce n'est pas trop mon domaine de préférence : On a jQuery comme grosse brique pour le javascript et le CSS est compose via des fichiers scss pour améliorer leur lisibilité. Toutes les assets (css, js, images) sont gérée par les outils npm qui se charge de les assembler, minifier etc. Les cadors dans cette partie sont pour le moment Sandhose et Situphen.
Coté back, ZdS se repose sur un environnement Python avec le framework Django. Le tout est divisé selon le pattern MVC.
- Les vues sont dans le dossier templates
- Les modèles sont dans les fichiers zds/[modules]/models.py
- Les contrôleurs sont dans les fichiers zds/[modules]/views.py
- Les [modules] représentent les "unités fonctionnelles" du site, comme le forum, les mp etc. Ils sont regroupés dans des dossiers du même nom. On retrouve dedans les fichiers de routing d'url, les contrôleurs, les formulaires, les modèles, les tests unitaires etc…
Bref, plein de choses que l'on (re)verra au fur et a mesure…
Pour se jeter dans l’arène, il y a deux voies royales :
- La QA, pas le truc le plus marrant, mais nécessaire pour avoir un site propre. C'est cool si tu peux en faire de temps en temps (et j'ai fait un joli topo a ce sujet : https://zestedesavoir.com/forums/sujet/1351/la-qa-pour-les-nuls/ )
- La correction de bugs "facile". Plus marrant que la QA, moins marrant que coder des nouvelles choses, ca reste cependant un excellent moyen de découvrir le code puisque ca permet de se concentrer sur une chose localisée.
Vocabulaire et infos diverses
Ceci est un message intégralement citer et anonyme, l'auteur de la discussion se reconnaîtra
Existe-t-il un résumé des dernières nouveautés/corrections techniques ? Il est toujours possible de consulter les dernières modifs au niveau des sources, mais il serait peut-être plus pratique d'avoir un résumé en français de ces choses-là ?
Si par "nouveautes des dernieres versions" tu veux connaitre le detail des choses dans la release en cours ou precedentes, alors je te conseille d'aller voir sur cette page : https://github.com/zestedesavoir/zds-site/milestones?state=closed . J'avais aussi fait un petit script pour faire des rapports automatiques : https://zestedesavoir.com/forums/sujet/1761/generateur-de-rapport-de-release-md
Ma deuxième question porte sur les QA. C'est bien l'acronyme/le synonyme de Pull-Request ? Si j'ai bien compris, il s'agit de tester les corrections de beugs juste avant la mise en prod' ?
Alors tu as faux et bon .
- QA = Quality Assurance = process pour s'assurer qu'on résout bien le problème et qu'on en amène pas de nouveau
- PR = Pull Request = mécanisme permettant de publier une demande de merge entre une branche et une autre (souvent une branche d'un contributeur vers la branche de dev du dépôt principal de ZdS).
- X va publier un correctif et faire une PR
- Y va alors faire la QA de la PR
- si Y déclare que tout est OK, alors un superuser fera le merge de la PR
La correction de beugs et les discussions sur l'avenir du site me plaisent beaucoup, mais est-ce qu'il y a également moyen de programmer de nouvelles fonctionnalités ?
Bien sur !
Il y a le choix !
- Soit tu veux faire de la grosse nouveauté (et qui risque alors d'avoir un impact assez gros sur le code) et dans ce cas on passe par une ZEP pour que les choses soient assez carrée et que l'on sache ou l'on va.
- Soit c'est une suggestion d'un membre qui a l'air d’être appréciée. ( https://zestedesavoir.com/forums/sujets/tag/6/suggestion/ )
- Soit c'est déjà dans les tickets de github et dans ce cas "fais toi plaisir !"
Si tu veux travailler sur "une grosse amelioration", il est souvent possible de travailler en tandem sur les ZEP (par exemple sur celle-ci, je n'aurais pas le temps de tout faire mais je sais pas si il y a des devs de dispo en ce moment)
Encore merci d'avoir pris le temps de me répondre.
Pas de souci !