Encadrement de devs

Je ne participe pas au code de ZdS, ou plus exactement, je ne code pas pour ZdS. Il me semble qu'il existe plusieurs raisons à cela, notamment les suivantes.

• Je ne parviens pas à m'organiser : n'ayant pas l'habitude de mener de gros projets, je gère mal mon travail. Notamment, j'ai tendance à négliger l'étape consistant à faire une maquette, et je me lance dans des trucs monstrueux, pour, au milieu, me rendre compte qu'il me faut tout refactoriser, et ce plus ou moins de manière bouclée. Autant dire que j'atteins rarement la fin.
• Je peine à me motiver sur le long terme : j'ignore la cause, mais le fait est que j'abandonne assez vite mes projets.

Aussi, je me demandais s'il ne pourrait pas être intéressant de fonctionner, de manière facultative, par binômes, avec un (ou plusieurs) développeur et une personne encadrant le travail de ce dernier.

L'encadrant interviendrait principalement sur les chantiers importants, typiquement l'implémentation d'une ZEP, et s'occuperait :

• d'aider les devs à s'organiser : limite conception/code, planning, etc.
• de réveiller les devs endormis (Eskimon le fait, je crois, sur l'ensemble du projet, et j'ai cru comprendre que c'était plutôt efficace)
• de relier le travail du dev à l'extérieur : il en est à telle étape, il aurait besoin de personnes pour faire de la QA, etc. Par exemple, si Dominus n'avait pas suggéré un Dévelopothon au niveau de la ZEP-12, aucune issue n'aurait probablement été créée (ou, du moins, en moindre quantité), et je n'aurais alors pas fait de QA (ni même consulté le dépôt).
• clarifier les issues : telle demande de QA n'est pas très explicite, etc. Ce dernier point peut sembler superflu, mais les débutants (au niveau contribution dans des projets libres) n'osent pas trop intervenir. Par exemple, j'ignorais au départ quoi faire devant une issue de la ZEP-12 portant le label need-qa mais exempte d'explications détaillées sur la marche à suivre.

Au-delà du fait que cela rendrait peut-être certains devs plus productifs¹, voire en inciterait d'autres à rejoindre le projet, il me semble que c'est très formateur, à la fois pour l'encadré et pour l'encadrant.

Notons tout de même que je n'ai aucune expérience en la matière, et que j'ignore si ce que je propose est viable dans le cas de ZdS, ni même judicieux de manière générale.

Merci.

Je suis "mitigé" face à ta proposition alors que quand je la lis, j'ai un grand sourire car je suis heureux que ce genre de choses vienne dans la dev-zone.

Alors pourquoi "mitigé"? Parce que "encore une structure". C'est vrai qu'il en faut dans un projet, mais quand je montre le process qualité de ZDS à des pros, ils me disent qu'on est hyper avancés (et qu'en gros, à part des tests fonctionnels automatisés, il nous manque vraiment rien).

Mitigé aussi car une partie des propositions que tu fais sont finalement tellement du bon sens qu'elles se sont mise en place toutes seules en fonction du besoin réel des devs.

J'insiste sur ça. Au début de la zep-12, j'ai tenté d'organiser les choses avec un redmine. Mais finalement au vue de notre manière de développer, ni pierre ni moi n'y avons participé. par contre quand Dominus a lancé la simple idée de Dévelopothon et de cahier des issues sur github, ça s'est vite mis en place. Pourquoi? Parce que nous étions suffisament avancés dans le projet pour que notre vision de ce qu'il restait à faire soit stable et claire. Du coup on pouvait dire "ça c'est un bug, ça c'est voulu, ça c'est pour plus tard", surtout on pouvait itentifier les "ça".

Idem pour la partie "binôme", la ZEP-12 a dès le départ été développée en binôme et c'est quand on a eu des manques qu'on a appelé à l'aide. Résultat, la communauté a répondu présente (Eskimon et Andr0 au départ, puis Hugo et toi). Donc ça marche déjà.

Cela marche d'autant plus que quand Andr0 avait essayé de faire l'API des MP seul, il s'était rapidement retrouvé à demander l'aide d'un binôme (je sais plus qui c'était).

Pour la partie "need-qa" c'est propre à la zep-12. Notre organisation n'était pas 100% iso avec upstream (c'est à dire avec le dépôt officiel). Quand tu as une PR sur upstream, elle nécessite toujours une QA et le problème réglé par cette PR doit TOUJOURS être décrit, sinon on te demande de le faire justement pour éviter que tu te retrouves dans la situation de tes débuts sur la zep-12. N'oublions pas qu'au départ les issues n'étaient destinées qu'à pierre et moi d'où leur rédaction succinte.

Maintenant, il y a une évidence : on ne se lancce jamais dans un projet aussi vaste qu'une zep (en le sens "dont l'ambition équivaut à l'ambition qu'on trouve dans une zep) seul, c'est une erreur.

PS : Eskimon fait un excellent travail de CDP.

Comme le dit artragis, ça fait toujours sourire ce genre de sujet. C'est mignon de voir des gens vouloir structurer les choses. Même si tu as plus que raison de créer ce sujet pour t'exprimer et de pointer du doigt la difficulté du projet pour faire participer de nouveaux contributeurs, c'est souvent le genre de truc qui passe à la trappe.

Ce que tu proposes aujourd'hui, c'est quelque chose qui a déjà été mis en place et mené en très grande partie par Eskimon. Il prenait sous son aile plusieurs nouveaux contributeurs pour les guider. En fonction de la personne, il donnait les tâches les plus adaptés à leur niveau et ça fonctionnait plutôt pas mal. Nous avons eu quelques PRs de ces personnes. Mais, à partir d'un moment, soit ces personnes n'ont plus le temps, soit il n'y a plus de nouveaux contributeurs à "former" ou peut-être que Eskimon en avait un peu marre. Ce qui est compréhensible puisque ça demande du temps non négligeable.

Cela marche d'autant plus que quand Andr0 avait essayé de faire l'API des MP seul, il s'était rapidement retrouvé à demander l'aide d'un binôme (je sais plus qui c'était).

C'est pas exactement ça. En fait, je suis toujours open à toutes les aides, même au plus débutant pour les guider dans les premiers pas et finalement, Hugo a bien voulu faire une des vues de l'API ce qui est déjà pas mal pour un débutant dans le dev de l'API (très différent du dev des vues du site).

PS : Eskimon fait un excellent travail de CDP.

<3 merci (Mais c'est pas mal faute, il y a une excellente équipe !)

Ce que tu proposes aujourd'hui, c'est quelque chose qui a déjà été mis en place et mené en très grande partie par Eskimon. Il prenait sous son aile plusieurs nouveaux contributeurs pour les guider. En fonction de la personne, il donnait les tâches les plus adaptés à leur niveau et ça fonctionnait plutôt pas mal. Nous avons eu quelques PRs de ces personnes. Mais, à partir d'un moment, soit ces personnes n'ont plus le temps, soit il n'y a plus de nouveaux contributeurs à "former" ou peut-être que Eskimon en avait un peu marre. Ce qui est compréhensible puisque ça demande du temps non négligeable.

En fait je suis toujours volontaire pour accueillir les nouveaux et les dirigés, mais je ne veux pas non plus leur courir après. En effet, j'ai reçu plusieurs fois des demandes de "mise sur la piste", du coup j'expliquais le fonctionnement, je proposais/assignais une tache, mais ca a très souvent été sans retour du candidat. Ne souhaitant pas imposer ni courir après les gens, je laissais couler (malheureusement).

Mais comme je pouvais dire à Andr0 récemment sur IRC, il est vrai que ces dernières semaines j'ai été beaucoup moins présent, ayant d'autres chantiers à mené IRL (et ayant noté une plus faible participation pendant les vacances de toute facon )

A noté que moi aussi je suis dispo pour aider les nouveaux si besoin !

@ Eskimon et Stiuphen : je serais intéressé d'avoir quelqu'un pour me diriger et tout alors. Ça se passe comment généralement ?

Je pense que tu peux commencer par regarder la documentation, le code et peut-être installer le projet. Connais-tu un peu Git et Github ? Normalement les tickets les plus simples à résoudre son ceux étiquetés "Facile". Néanmoins, si tu penses pouvoir résoudre les autres, essaye et commente sur le ticket si tu as besoin de plus d'informations pour résoudre le bug, ou coder la fonctionnalité !

En cas de problème, n'hésite pas à nous envoyer un MP ou à passer sur les canaux zestedesavoir et zds-dev du chat SmoothIRC (irc.smoothirc.net). Tu ne connais pas IRC ? Pas de problème, tu peux y accéder directement via son webchat !

J'espère que ça t'aide !

Salut Karnaj, je me remets un peu dans le projet et si tu as des questions n'hésite pas. Je vais devoir me mettre à jour et on peut faire d'une pierre deux coups ! Le code est assez important et on a tous une partie du code qui est un peu difficile à comprendre, surtout au début.

Très bien, je saurais qui contacter en cas de besoin.