Faire une pause pour poser les bases

Bonjour à tous,

Ce sujet a soulevé un certain nombre de problèmes qu'il est nécessaire, je pense, de régler dans les plus brefs délais. J'ouvre donc le débat pour déterminer ce qu'il ne va pas actuellement dans la gestion du projet et comment on pourrait y remédier. Ce message se veut une amélioration de celui-ci.

Il m'est avis que le souci majeur est le manque d'organisation.

Premièrement, il y en a dans tous les sens : dans la Dev Zone, dans le forum des bugs et des suggestions, sur IRC, sur Github… Certains problèmes sont répertoriés sur l'un et pas sur l'autre, certains débats ont lieu sur l'autre et pas sur l'un… Se mettre à la page et, encore pire, intégrer l'équipe de développement devient laborieux (sans compter les points considérés dans le sujet mentionné ci-dessus). Il faudrait centraliser ou alors synchroniser.

Mais ce bazar ne sort pas de nulle part. Pour moi, il est dû à un manque de suivi des activités et à l’absence d'attribution de rôles clairs. Des issues sont ouvertes à tout va, certaines ZEPs sont commencées par certaines personnes… En fin de compte, j'ai l'impression que chacun ignore qui fait quoi, quand, avec qui… Et si on ignore cela, comment peut-on se décider à intégrer une équipe de résolution d'issue ? Certes, il est laborieux d'établir un planning rigoureux pour les problèmes mineurs, mais il faudrait au moins le faire pour les ZEPs.

Tout cela a un impact non négligeable sur le flot de nouveaux contributeurs. Aujourd'hui, il me semble qu'on a atteint un point auquel seuls ceux réguliers peuvent comprendre le code, sa structure et l'organisation globale, uniquement du fait de leur habitude. Vous imaginez le mec qui connait pas Github ? Avant même d'être confronté au calvaire de l'installation, il est découragé par le manque de clarté : « mais… je fais quoi moi ? Où ? Comment ? Avec qui ? On m'avait pourtant dit que tout le monde était le bienvenu… l'accueil s'il vous plait ? ». Je suis tout à fait conscient que l'équipe est ouverte, qu'une personne se portera volontaire pour répondre aux questions… Mais autant le faire systématiquement, non ? En écrivant, bien visiblement, tout ce qu'un contributeur potentiel devrait savoir pour devenir autonome.

C'est pourquoi je suggère de faire une pause dans la course aux nouvelles features et de pallier aux manques actuels. Plusieurs suggestions :

• Une documentation claire et complète :

Première chose, expliquer l'installation du site de sorte que ce soit simple à effectuer (cf : le sujet mentionné plus haut) : les contributeurs au code sont bénévoles et ne souhaitent pas nécessairement faire cent mille réglages avant de pouvoir apporter leur pierre à l'édifice.

Éclaircir la structure globale du projet, l'agencement des dossiers et des fichiers. Bien que les noms soient explicites, il faudrait pouvoir atteindre la partie du code ciblée quasiment sans chercher. Autrement dit, donner une vision globale du code (peut-être que des connaissances en Django sont requises).

Expliciter les concepts. Un tutoriel, comment c'est représenté ? L'éditeur markdown, il repose sur quoi ? Etc.

• Un code propre :

Une fois qu'on a déniché le fichier auquel on souhaite apporter des modifications, on aimerait bien comprendre le code rapidement. Pour cela, il faut qu'on ait des repères, ce qui n'est possible qu'avec un code uniforme. D'où : un code en anglais (par exemple, mais ça me semble nécessaire) et respectant des conventions (PEP8 obligatoire). En outre, les commentaires sont indispensables : ils permettent d'éclairer les passages obscurs et un peu techniques mais aussi de se déplacer rapidement parmi les fonctions.

Une PR ne devrait pas être mergée si elle ne respecte pas ces critères (et/ou d'autres).

• Une organisation solide :

Comme précisé, je ne suis pas un expert en la matière, ce sujet en témoigne. La meilleure façon de faire, me semble-t-il, c'est de tout planifier (ou presque) : faire comme pour les ZEPs, mais dans tout le projet.

En premier lieu, on constate le problème, le besoin, le truc à faire. Souvent, ça passe par les forums « Dev Zone » et « Bugs et suggestions ». On le définit clairement. Puis on décide de la méthode pour le résoudre et on explicite cette méthode : on dit ce qu'on va faire avant de le faire. Ce que m'a conseillé GuilOooo dans le sujet ci-dessus fonctionne très bien : on fait comme si on devait expliquer à un autre comment il doit s'y prendre, histoire que ça ne soit plus qu'une question de dactylographie après ça (et une connaissance du langage). C'est long, c'est laborieux, mais ça permet deux choses très importantes : vérifier qu'on a bien compris, que tout est clair et en garder une trace, de sorte que tout le monde puisse le faire à notre place. Une fois cela effectué, il faut dresser une équipe pour répondre au besoin et organiser le travail (ça dépend du nombre de personnes, de leurs compétences…). La prochaine étape, c'est notifier les autres de l'avancement. Effectivement, maintenant qu'ils savent quoi faire, comment le faire précisément, il faut qu'ils sachent où ceux qui s'en chargent en sont, ce qui leur permettra de facilement intégrer l'équipe, de juger du travail accompli… bref, de participer même s'ils ne sont pas « dedans » (ce qui fait que l'équipe originelle n'a pas d'importance). Enfin, une fois le travail effectué, il faut vérifier que ce qui a été fait est correct : c'est la QA.

Vous remarquerez que j'ai employé le pronom « on » au début du paragraphe et que ce n'est pas très explicite. En fait peu importe, et c'est justement l'intérêt d'une telle démarche : tout le monde peut participer et, ici, « pouvoir » ne signifie pas « en avoir l'autorisation » mais bien « en avoir la possibilité ».

Au plaisir. =)

Je soutiens l'initiative. Je pense qu'on a besoin d'un endroit qui centralise toutes les infos et de sujets sur le forum pour accueillir les nouveaux motivés.

Cependant je tiens tout de même a relativiser un truc : tu ne pourra jamais faire un truc super méga simple. Pourquoi ? Parce que on est un projet énorme et complexe. Sérieusement c'est triste mais on ne pourra jamais simplifier tout au point que n'importe qui puisse rentrer dedans. Certaines personnes n'auront pas le niveau et ne pourrons pas faire beaucoup plus que les tests sur la preprod.

Ce n'est pas de l'élitisme mais il faut être conscient que zds est un très gros projet et que par conséquence on a forcément besoin de procédure qui sont parfois lourde. Par exemple le passage par qa, le git-flow, etc. Ça peut sembler lourd et ralentir le dev, mais on a pas le choix vu notre taille.

Donc oui on peut simplifier, oui on peut faciliter l'entrée dans l'équipe technique mais il faut être conscient que c'est de l'investissement et qu'on ne peut pas tout simplifier non plus. On ne peut pas non plus re-expliquer toutes les commandes git dans nos procédures, ce n'est pas notre job. Tout au plus on peut faire un tuto sur git sur ce forum.

Oui oui, bien sûr. J'aurais dû préciser : par « tout le monde », j'entends les personnes ayant les connaissances techniques minimales requises. Sinon, à ce compte là, il faudrait faire un tutoriel Python, Django, HTML, CSS… pour que tout individu puisse participer !

L'avantage de concevoir en détails le code avant de programmer, c'est que tout le monde (ayant un minimum de connaissances en programmation) peut participer : être à l'aise en Python ne sera requis qu'à la toute dernière étape, pour traduire les explications en code (qui, idéalement, reviendra quasiment à de la dactylographie).

organisation

Mais ce bazar ne sort pas de nulle part. Pour moi, il est dû à un manque de suivi des activités et à l’absence d'attribution de rôles clairs. Des issues sont ouvertes à tout va, certaines ZEPs sont commencées par certaines personnes… En fin de compte, j'ai l'impression que chacun ignore qui fait quoi, quand, avec qui… Et si on ignore cela, comment peut-on se décider à intégrer une équipe de résolution d'issue ? Certes, il est laborieux d'établir un planning rigoureux pour les problèmes mineurs, mais il faudrait au moins le faire pour les ZEPs.

je pense que ce ressenti est principalement dû à ce que tu dis au départ :

je ne suis [pas] contributeur au code

En effet, en tant que contributeur, je trouve la communication interne plutôt bien organisé.

dev des ZEP

En ce moment 3 ZEP sont en développement, chacune a un référent bien identifié :

• ZEP 02 (aka API) + ZEP 17 (aka API membre) = Andr0
• ZEP 03 (aka demande d'aide)= Eskimon
• ZEP 05 (aka refonte markdown) = Kje
• ZEP 12 (aka refonte du modèle de donnée pour les tutos) = pierre_24 (auteur) et moi (collaborateur principal)

les tickets github

Viennent ensuite les issues : typiquement, je sais qu'avec pierre_24 et moi ça marche comme ça, que plusieurs autres contributeurs sont sur le même modèle : dès qu'on a le temps pour une issue on demande à ce qu'elle nous soit assignée et on y travaille. Comme ça chacun sait ce qu'on fait à quel moment.

Firm1 a tendance à faire du push (i.e d'un coup il corrige cinq issue/fait cinq PR) à cause de ses horaires de disponibilités trop peu réguliers. Mais on se rend vite compte et on s'adapte.

Et globalement sauf pour le front pour lequel je ne peux pas parler (je ne sais pas comment sandhose et alex-D organisent la synchronisation des topics de bug et "les petits pixels") mais pour le back, il y a très peu d'erreur de synchronisation. Par contre étant donné que GitHub est notre outil de ticketting officiel, logique que GH ait plus de ticket ouverts que le forum n'a de sujets "bug".

pour moi, il y a un gros problème. On fait de l'agilité, bien. Mais là on est tous en télétravail. Du coup on n'a aucun outil style tableau de tâche, niko niko…

On a juste les zest'meeting. Encore une fois ces derniers sont tout à fait bien organisés, communiqués et ouverts. On sait qui parle pour quoi et quand. On s'est rendu compte que le premier (2h30) était trop long, on a raccourcis le second (1h30-1h45) et on aimerait que maintenant tous tiennent en 1h.

Et ces zest'meeting sont un vrai condensé de ce qu'il se passe. Ils permettent de résoudre pas mal de problèmes (suffit de voir les log/résumés des deux premiers zest'meeting pour se rendre compte qu'ils sont efficaces, vraiment !)

(Edit : désolé , appui intempestif sur mon touchpad qui a validé le message)

La faiblesse des outils existants

GitHub possède plusieurs problèmes pour ce qui est du suivi de projet :

• une tâche = 1 assignee, même une ZEP, même si un binôme s'est déjà mis en branle pour qu'un code la fonctionnalité, un le test et que globalement il y ait une belle QA;
• pas de vue graphique de l'évolution des tâches à faire;
• difficulté à prioriser les tâche, on a les tags et les filtres qui vont avec mais du coup on a du mal à voir ce qui est priorisé car bloquant l'expérience utilisateur ou parce que la fonctionnalité est un souhait fort de l'équipe;
• pas de possibilité d'entrer le temps passé à développer et QA, ce qui empêche toute analyse des goulet d'étranglement.

Le cycle de vie du projet

Très clairement, on ne peut pas faire un process ultra long avec du V ou du W. On est obligé de faire de l'agile. Il faut qu'on soit rapide à mettre en place quelque chose.

C'est pour ça qu'on met en gros une version toutes les deux semaines. Mais c'est assez complexe de travailler à la fois sur une ZEP qui demande une centaine d'heures de dev, un hotfix sur la RC en cours et un bugfix sur la version dev.

Actuellement on a des problèmes de build car npm bug. A une époque c'étaient les dépendances latex qui avaient mis le boxon dans notre processus de build (juste pour dire que de toute façon on a toujours eu des soucis, c'est pas le front qui en soit gène).

Si quelqu'un, même qui ne code pas, connaît un bon outil pour mettre le build dans la stratosphère, il aura un nombre incroyable de bières.

En effet, en tant que contributeur, je trouve la communication interne plutôt bien organisé.

Justement, il ne faudrait pas être un contributeur ancien et régulier pour se rendre compte de cela. Soit j'ai personnellement un problème, soit tout cela n'est pas assez clair pour les autres. Bien sûr, il faut que ça le soit si vous souhaitez obtenir des contributions en plus. Mais le fait que tu dises ça explique pourquoi ça manque : quand on est dans le truc, on a l'impression que tout est clair et défini.

En ce moment 3 ZEP sont en développement, chacune a un référent bien identifié :

• ZEP 02 (aka API) + ZEP 17 (aka API membre) = Andr0
• ZEP 03 (aka demande d'aide)= Eskimon
• ZEP 05 (aka refonte markdown) = Kje
• ZEP 12 (aka refonte du modèle de donnée pour les tutos) = pierre_24 (auteur) et moi (collaborateur principal)

• Où puis-je consulter la conception technique de ces ZEPs ?
  • Pourquoi cette ZEP ? Il y a le sujet associé pour ça.
  • Comment résolve-t-on le problème, conceptuellement parlant ? Il y a le sujet associé pour ça.
  • Comment résolve-t-on le problème, Pythoniquement parlant ? Quelles classes seront écrites ? Pour faire quoi ? Communiquer avec qui ?
• Où puis-je consulter l'organisation prévue pour le développement ?
• Où puis-je consulter leur avancement ?
• Comment puis-je intégrer l'équipe ?

Là encore, je le répète, ce n'est pas obligatoire, vous avez fait sans jusqu'ici et le chemin parcouru est admirable, mais ça implique d'exiger un important effort d'intégration de la part des contributeurs potentiels ce qui, honnêtement, est très rebutant quand on est bénévole.

Viennent ensuite les issues : typiquement, je sais qu'avec pierre_24 et moi ça marche comme ça, que plusieurs autres contributeurs sont sur le même modèle : dès qu'on a le temps pour une issue on demande à ce qu'elle nous soit assignée et on y travaille. Comme ça chacun sait ce qu'on fait à quel moment.

On sait ce que tu fais, mais pas comment tu comptes le faire, ni où tu en es. Certes, les issues mineures ne nécessitent pas un tel déploiement de planification, mais dans certains cas je pense que ça pourrait être utile, si jamais quelqu'un veut se greffer, considère que tu es long… Il faudrait définir tout cela i.e. ce qu'il faut planifier et comment le faire. Bien sûr, on peut toujours vérifier dès que tu nous fais part du code, mais je ne suis pas certain qu'il faille procéder dans ce sens (sauf dans certains cas simples à définir).

Et ces zest'meeting sont un vrai condensé de ce qu'il se passe. Ils permettent de résoudre pas mal de problèmes (suffit de voir les log/résumés des deux premiers zest'meeting pour se rendre compte qu'ils sont efficaces, vraiment !)

Where are they ?

Ce que je ne comprends pas c'est pourquoi devoir attendre les Zest'Meetings pour s'organiser, acquérir une vision globale du projet… ? D'autant plus que les contributeurs potentiels n'en ont pas conscience.

Très clairement, on ne peut pas faire un process ultra long avec du V ou du W. On est obligé de faire de l'agile. Il faut qu'on soit rapide à mettre en place quelque chose.

C'est quoi du V et du W ? Pourquoi vous êtes obligés de faire de l'agile et d'être rapides ?

Comme il y a des contraintes à ça et qu'on ne peut faire autrement, il faudrait soit admettre qu'il est impossible à une personne extérieure de s'intégrer facilement, soit lui expliquer comment faire. Dans un premier temps, vu que la résolution de problèmes intempestifs semble mouvementée, peut-être faudrait-il diriger les nouveaux vers les trucs plus statiques, du genre doc ou ZEPs, pour qu'ils se familiarisent. Mais là, on repart au niveau de la deuxième citation de ce message.

C'est quoi du V et du W ?

Pourquoi vous êtes obligés de faire de l'agile et d'être rapides ?

• Faciliter l'expérience utilisateur (on a un public de débutant, c'est une killer feature que de corriger du jour au lendemain tout bug d'interface)
• Utiliser au mieux une équipe qui n'est pas à temps complet sur le projet et qui est géographiquement éclatée
• Assurer au maximum que ce qui a été codé fonctionne.

Where are they ?

ici

Je pense que tout est résumé ici.

Dans n'importe quel projet, à partir du moment où tu veux contribuer, il faut essayer un minimum de comprendre son fonctionnement. On a un projet très jeune, avec une très forte activité et une équipe bénévole. On est tous d'accord pour dire qu'il y a des soucis et ouvrir un n-ième sujet n'y apportera rien. Je crois que le prochain ZDS Meeting va essayer de régler pas mal de problèmes qu'on peut avoir.

Après @Vayel : as-tu déjà essayé de contribuer au code ? Parce qu'il est facile de critiquer mais lorsque j'ai voulu participer j'ai pas eu de problème (OK j'ai raté ma première PR mais il n'y a pas mort d'homme). Ça m'agace un peu que des gens qui n'ont qu'une vue extérieure viennent se permettre ce genre de message.

Première chose, expliquer l'installation du site de sorte que ce soit simple à effectuer (cf : le sujet mentionné plus haut) : les contributeurs au code sont bénévoles et ne souhaitent pas nécessairement faire cent mille réglages avant de pouvoir apporter leur pierre à l'édifice.

Read the doc: https://github.com/zestedesavoir/zds-site#installation-dune-version-locale-de-zds.

Éclaircir la structure globale du projet, l'agencement des dossiers et des fichiers. Bien que les noms soient explicites, il faudrait pouvoir atteindre la partie du code ciblée quasiment sans chercher. Autrement dit, donner une vision globale du code (peut-être que des connaissances en Django sont requises).

Faut peut-être apprendre les bases de Django : https://zestedesavoir.com/tutoriels/232/developpez-votre-site-web-avec-le-framework-django/.

Expliciter les concepts. Un tutoriel, comment c'est représenté ? L'éditeur markdown, il repose sur quoi ? Etc.

Read the doc: http://zds-site.readthedocs.org/fr/latest/tutorial/tutorial.html

Une fois qu'on a déniché le fichier auquel on souhaite apporter des modifications, on aimerait bien comprendre le code rapidement. Pour cela, il faut qu'on ait des repères, ce qui n'est possible qu'avec un code uniforme. D'où : un code en anglais (par exemple, mais ça me semble nécessaire) et respectant des conventions (PEP8 obligatoire). En outre, les commentaires sont indispensables : ils permettent d'éclairer les passages obscurs et un peu techniques mais aussi de se déplacer rapidement parmi les fonctions.

Le code est en anglais, la PEP-8 respectée de partout. On est pas encore full PEP-257 mais ça se comprend un minimum.

Une PR ne devrait pas être mergée si elle ne respecte pas ces critères (et/ou d'autres).

Bonjour travis : https://travis-ci.org/zestedesavoir/zds-site

Bref je vais m'arrêter là.

On est tous d'accord pour dire qu'il y a des soucis et ouvrir un n-ième sujet n'y apportera rien.

Où sont donc les n-1 autres ? Où sont répertoriés ces problèmes ?

Après @Vayel : as-tu déjà essayé de contribuer au code ? Parce qu'il est facile de critiquer mais lorsque j'ai voulu participer j'ai pas eu de problème (OK j'ai raté ma première PR mais il n'y a pas mort d'homme). Ça m'agace un peu que des gens qui n'ont qu'une vue extérieure viennent se permettre ce genre de message.

J'ai lu la doc et me suis rendu compte que je n'aurai pas le temps pour me plonger sérieusement dans le projet. D'ailleurs, tu as raison, le problème vient certainement du fait que je ne suis pas un contributeur potentiel. Je pensais que ça venait du projet mais c'est probablement pas le cas. Toutes mes excuses.

Pour tout ce qui suit, il ne me semble pas avoir affirmé que ce n'était pas fait. Seulement, je n'ai vu aucun texte définissant ces points comme devant être respectés (et l'étant). Du coup, quand on est extérieur au projet, on n'a pas conscience de tout cela. La seule vision qu'on a du truc (du moins que j'ai), c'est un ensemble d'issues, de PR, des messages sur le forum, sur GH, des gens qui font des choses mais on ignore quoi et comment, où ils en sont… Alors soit on a le courage d'intégrer le projet même si on n'y comprend rien, soit on fait demi-tour. Après :

Le projet devient de plus en plus complexe, de plus en plus volumineux. Si vous ne dites pas aux contributeurs potentiels quoi faire exactement (autre que "Lis-donc la doc et apprends Django"), je doute que vous en recevrez beaucoup. Et leur dire quoi faire, ce n'est pas uniquement, selon moi, expliquer les concepts de base dans une doc, mais aussi expliquer où en est le projet et où il va. D'où, je pense, indiquer ce qui est (va être) fait, par qui, comment, où ça en est (dans la mesure du possible)… Après, je suis peut-être un programmeur prétentieux imbu de ma personne et refusant de faire le moindre effort pour intégrer le projet. Cette piste est à explorer aussi.

Bref, je suis navré que tu aies mal pris mon message. Je pensais avoir été suffisamment explicite quant au fait que je ne souhaitais pas vous balancer des critiques à la figure mais seulement souligner des points qui me semblaient problématiques.

Je ne sais que trop dire devant ce topic… en gros il y a un mélange assez délicat à trier entre :

1. Des remarques pertinentes et intéressantes
2. Des remarques qui font doublon avec ce topic
3. Des remarques qui n'en sont pas, puisqu'elles concernent des problèmes inexistants. Cf ce message.

En gros, voici ce que je peux dire pour répondre aux principaux arguments :

1. Zeste de Savoir est un gros projet. Aussi dommage que ça puisse paraître, il est donc hors de question d'avoir des docs Git, Django, etc… dans nos propres docs. On a besoin que les personnes qui développent Zeste de Savoir connaissent déjà ces outils, ou sachent se renseigner seules sur ces points (ce qui a déjà été fait et fonctionne très bien d'ailleurs).
2. Il manque clairement une doc d'arrivée sur le projet et la présentation des docs actuelles est décourageante pour le nouvel arrivant. On a un travail en cours sur ce sujet.
3. Au nouveau de l'organisation, on a hélas une triste réalité à gérer : on fait ce qu'on peut avec les ressources qu'on a, c'est-à-dire des développeurs éparpillés, à la disponibilité aléatoire et prédictibilité, venus de moult horizons. Ceci a une conséquence directe : l'organisation est obligatoirement souple et légère. Ça implique en particulier de tolérer des choses à ne pas faire sur un projet pro ou personnel.
   En particulier, toute forme de processus long et laborieux qui n'est pas strictement indispensable est à éviter. Ceci implique la conception détaillée dans les cas hors cas pathologiques¹.
4. Concernant le code, à ce que j'en sais il n'a pas une organisation orthodoxe pour Django et manque un peu de doc, mais il reste propre (PEP8 en particulier). Les points d'amélioration ont déjà des ZEP ou des issues en cours.

J'espère que c'est plus clair ainsi. Certes, on a une marge de progression ; mais n'oublions pas qu'on a un gros projet avec des ressources limitées ; vouloir s'enfermer dans un carcan rigide c'est suicider le projet à court terme. On se doit d'être efficaces.

Il manque clairement une doc d'arrivée sur le projet et la présentation des docs actuelles est décourageante pour le nouvel arrivant. On a un travail en cours sur ce sujet.

Clairement c'est le point important qui, une fois fais, empechera ce genre de sujets.

Je remarque qu'au long de ces interventions, ici, dans l'autre sujet ou sur la news de la V 1.1, Vayel a surtout mit en évidence qu'un nouveau, aussi compétent soit il, ne peut pas facilement savoir.

On a besoin d'un document qui a minima dispatche les nouveaux arrivants cers les différentes ressources et documents à sa disposition pour cerner l'organisation et le projet. Toutes les autres questions/réponses peuvent en être dans l'ensemble déduite, cf la réponse de gustavi.

C'est donc surtout pour moi un probleme d'aiguillage des nouveaux/non-contributeurs qu'il faut faire, pour qu'ils trouvent les réponses aux questions qui les intéressent.

Partir sur des cas d'utilisation ptêtre ? Ca peut être une piste ?

Je veux contribuer ?

• Je connais Django ?

• Je sais me servir de Git ?

• J'ai choisi une issue "Facile" ?

• J'ai installé le projet en local ?

Ou :

Je veux aider ?

• J'ai pas de connaissance en Django

• Je sais me connecter à la preprod

• J'ai repéré une issue à QA

• J'ai reproduit le bug

• J'ai bien vérifié qu'il était corrigé

Une espèce de carte dans ce style ? Est-ce-que ça t'aurait aigillé Vayel ? Ou est-ce-que tu recherches des infos purement techniques ?

Mon avis est un peu le même que celui de SpaceFox ici, ce qui nous manque c'est surtout le point d'entrée quand on veut rentrer dans le projet. Quand on fait partie du truc c'est sur qu'on connait comment ça se passe, mais quand on ne connais pas, ça peut sembler complètement bordelique.

Je l'ai déjà mentionné ailleurs, je trouve toujours notre utilisation de GitHub assez désastreuse. Encore récemment j'ai vu passé un message qui expliquait la signification d'un tag. Si même ceux qui sont dans le projet ne comprennent pas les tags utilisés (c'est normal ce n'est documenté nul part) comment les gens extérieurs peuvent comprendre quelque chose. Idem pour les notions milestones, etc. Bref, si je me mets à la place du nouveau venu, je n'ai pas envie d'ouvrir la marmite.

Pour moi, les points intéressant à regarder sont :

• on devrait avoir une page sur le site dispo via le footer sur laquelle on présente les différentes manières de contribuer en fonction des profils. Je veux faire du JS, qu'est ce qu'il y'a à faire au niveau du code en JS ? Je veux faire du HTML5/CSS3, qu'est ce que je dois lire en priorité ? Je veux faire du Django, etc. Bref, ce que Javier vient de décrire ci-dessus, avec des liens qui renvoi vers ce qu'il faut lire en premier.
• centraliser la documentation.
  • Le fichier workflow.md par exemple devrait se retrouver ici
  • La documentation du front-end idem
  • Comment et ou joindre les développeurs en général (Zest'Meeting, IRC, DevZone, etc.)
  • Savoir comment est organisé en interne le truc (DTC, QA, FRONT-END, BACK-END, etc.) avec une simple image pour illustrer le process.

Je crois que si on réussi à présenter convenablement tout ça, on devrait pouvoir rendre ça plus accessible au nouvel arrivant. Car même si le projet est gros, on peut très bien travailler sur certains morceaux sans rien casser.

on devrait avoir une page sur le site dispo via le footer sur laquelle on présente les différentes manières de contribuer en fonction des profils

Ca me fait penser a ca (pour reparer ton git/commit) qui se propose de te balader a la bonne ancre en te posant des questions… C'est con mais ca marche ! http://sethrobertson.github.io/GitFixUm/fixup.html

on devrait avoir une page sur le site dispo via le footer sur laquelle on présente les différentes manières de contribuer en fonction des profils. Je veux faire du JS, qu'est ce qu'il y'a à faire au niveau du code en JS ? Je veux faire du HTML5/CSS3, qu'est ce que je dois lire en priorité ? Je veux faire du Django, etc. Bref, ce que Javier vient de décrire ci-dessus, avec des liens qui renvoi vers ce qu'il faut lire en premier.

Attention à ne pas mélanger deux choses très distinctes : "Par où commencer" (ce qui est stable) et "ce qu'il y a à faire" (qui est inhérent aux développements du moment).

Quant aux tags, il y a un mélange assez compliqué entre ceux automatiques et ceux manuels ; et en plus certaines informations ont du mal à passer en interne (c'est au moins la 3ème fois que j'explique la signification du tag "infra" par exemple).

Pour le reste, 100% d'accord. J'essaie de commencer quelque chose en ce sens ce soir si j'ai un peu de temps.

En effet.

Les deux en fait. Comme précisé plusieurs fois plus haut, ce n'est pas aux développeurs du site d'enseigner les outils aux contributeurs potentiels. Si je ne maîtrise pas Git, soit j'apprends, soit je ne contribue pas, soit d'une autre manière que ce soit.

Par contre, ce que le nouvel arrivant voudra connaître, c'est la façon dont sont utilisés les outils. Pour Django, ça se résume à lire la doc, mais pour Git par exemple, ça dépend du workflow suivi, des tags… C'est donc des informations techniques qu'il serait judicieux de détailler/rendre visibles.

Oui fois qu'on est un peu plus renseigné sur la structure globale du projet, on aimerait savoir comment y participer. Que faire ? Où ? Comment ? Quand ? Parce que commiter, c'est simple pour ceux qui en ont l'habitude, mais le nouveau, même s'il maîtrise Git, ne saura pas trop quand s'impliquer dans quoi. C'est dommage, parce que ce projet communautaire attire une foule de développeurs (me semble-t-il).

Ca, ce sont les pistes pour participer de manière générale. Après, il y a le contexte courant : les ZEPs en cours, les issues pressantes… Comme l'a dit SpaceFox, il semble impossible de tout planifier. Mais je pense qu'il faut un lieu où sont décrites les tâches en cours, par qui elles sont prises en charge et ce qui est prévu. Sinon, même si on connait par cœur Django, Git, le zestflow… ben on ne saura pas où ça en est actuellement, ce qui est problématique et pour les nouveaux et pour les contributeurs irréguliers. Alors certes, je me suis emporté et il est peu judicieux de décrire en détails la façon dont vont être faites les choses, mais je pense très sincèrement qu'une personne extérieure aimerait (c'est mon cas) pouvoir connaître l'avancement du projet, des tâches en cours… Ca permettrait même aux non-contributeurs de suivre le projet à distance et de l'intégrer facilement au moment souhaité.

En somme :

• Comment sont spécifiquement utilisées les technologies dans le projet : si je participe, comment devrai-je m'organiser ?
• Comment participer : mais au fait, que puis-je faire ?
• Comment mettre en place tout ça techniquement (i.e. l'installation : déjà expliquée) : bien, je me lance ! Mais comment je fais ?
• Ce qu'il se passe en ce moment et ce qu'il est prévu d'effectuer (sans détailler la façon de faire : trop lourd à mettre en œuvre) : j'ai du temps de libre et pas de tâche en cours, à quoi je m'attèle ?
• Et surtout : tout cela bien visible !

En espérant ne pas paraître trop exigeant. Je veux bien aider à ça, au moins vous donner mon opinion de contributeur potentiel sur ce qui aura été fait.

Sinon, pour revenir au fait d'expliquer en détails les choses prévues (notamment pour les ZEPs), SpaceFox m'a fait prendre conscience du fait que tout organiser de sorte que ce soit clair pour n'importe qui (de techniquement "compétent" du moins) est illusoire. Seulement, si on ne le fait pas un minimum, comment faire pour intégrer une équipe de développement à part lire le code produit pour deviner (si, encore, je parviens à le dénicher) ? Par exemple, si je veux soutenir Kje dans sa noble quête markdownesque, comment faut-il que je m'y prenne ? Dans le premier message du sujet associé à cette ZEP, il y a uniquement les grandes lignes de la solution retenue. Je peux bien sûr lire les cinq pages du sujet, mais il y en a déjà certaines qui débattent de la solution à adopter, ce qui a été fait. Du coup, c'est une vraie question, comment fais-je pour aider Kje, sans passer des heures à chercher un moyen de le faire ?

Merci. =)

Du coup, c'est une vraie question, comment fais-je pour aider Kje, sans passer des heures à chercher un moyen de le faire ?

Tu m'envoie un mp comme deux personnes l'ont fait et des que j'ai un peu de temps, je te guide.

Pourquoi ne pas directement mettre ça dans le premier message ? Je suis peut-être empoté, mais s'il faut que les gens demandent qui il faut contacter avant d'envoyer un MP à cette personne, ça requiert un effort de la part du contributeur a priori non nécessaire, ta présence est obligatoire et ça te donne du travail en plus.

Pour que tu puisses te lancer, il faut bien que tu prennes contact avec quelqu'un de l'équipe de développement. Ça me paraît logique. La ZEP sur la refonte du MD de ZdS c'est Kje qui l'a écrite donc, si tu veux aider, il me paraît logique que ça soit lui qu'il faut contacter. Aussi, nous savons parfaitement qui s'occupe de quoi dans l'équipe de dév'. Donc tu peux envoyer un message à n'importe pour dire : « j'aimerai aider au MD, vers qui je dois me tourner ? », et le dév' te répondra sans te mordre un pseudo.

Aussi, si tu veux pas direct passer le MP tu poster sur le sujet de la ZEP ou, si tu n'es pas très timide, venir sur le canal IRC, si tu veux un contact direct. Je sais, je me répète avec cet IRC, mais je trouve cela dommage que de futurs contributeur ne viennent pas direct au contact de l'équipe de dév'.

Pourquoi devraient-ils y être obligés ? Personnellement, ça me semble plus simple de tout écrire sur le papier et de mettre ce dernier bien visible. C'est peut-être moins humain, mais on obtient ainsi directement ce qu'on cherche (a priori). Rien qu'IRC, je ne connais que de nom. Et je n'ai pas particulièrement envie d'approfondir le sujet uniquement pour participer bénévolement à un projet.

J'avoue ne pas comprendre ce principe de "il suffit de demander". Pour vous, contributeurs réguliers, ça vous paraît peut-être naturel. Pour moi, extérieur au projet, ça me semble un peu laborieux et peu clair. Après, il ne s'agit que de mon opinion.

Vayel, est-ce-que tu as déjà contribué à un projet open source auparavant ?

Je comprends les remarques sur le manque d'aiguillage. OK. Ca me semble être une remarque légitime et les quelques intéressés y ont répondu plutôt positivement.

Reste à trouver la bonne façon de réorganiser les docs. On en a d'ailleurs parlé dans d'autres topics. L'idée d'une carte de décision m'a traversé l'esprit et ça fait deux fois que je l'émets (dans un commentaire de news et dans ce topic même). Ça pourrait prendre cette forme, ou une autre.

Mais partir dans l'idée "je vais contribuer de mon côté" et je vais avoir toutes les informations dont j'ai besoin sans jamais poser une seule question ou contacter qui que ce soit, ça ne m'est jamais arrivé. Même pour des corrections de typo dans des bibliothèques que j'utilise j'ai du naviguer dans des Google Groups pour aller demander si c'était normal qu'on me demande de signer un CLA ou ce genre de bêtises.

Y'a vraiment que pour des petits projets persos que j'ai corrigés (genre un fix dans une lib JS très simple) que ça s'est passé directement sur Github. Dès que le projet est "gros", ça passe par une démarche du contributeur. On voudrait toujours que ce soit immédiat pour tout le monde, mais c'est illusoire. On peut s'en rapprocher, mais envoyer un MP, répondre sur un forum, participer à une mailing sera quasi-toujours nécessaire.

NB : les ZEP en tant que "spec ouvertes" sont déjà assez rare et sont sans doute les mieux organisées que j'ai jamais lues. Généralement c'est un fil Github incompréhensible ou un Google Group ou ça digresse sur plus ou moins n'importe quoi jusqu'à ce qu'un "lead" prenne les choses en main et écrive une spec.