Proposition : création d’un rôle de « consigliere » pour fluidifier la gestion des PR / issues GitHub

Discuter entre Dolibarriens
1

Bonjour à toutes et tous,

Je souhaiterais ouvrir une discussion autour de la gestion actuelle de GitHub (PR / issues) et proposer la création d’un rôle dédié que j’appellerai, faute de meilleur terme, un « consigliere ».

Constat actuel

Aujourd’hui, on constate :

  • ~300 Pull Requests ouvertes

  • près de 900 issues

  • à titre personnel, une cinquantaine de PR que j’ai soumises et qui sont toujours en attente, certaines étant destinées à être clôturées automatiquement au bout d’un an faute de traitement.

Ce volume important est parfaitement compréhensible au regard de la taille du projet et du nombre de contributeurs, mais il crée aussi :

  • de la frustration côté contributeurs,

  • une charge énorme sur la personne qui merge les PR (Laurent),

  • et un risque de découragement, même pour des contributions de qualité.

Proposition : un rôle de « consigliere »

L’idée serait de créer un rôle intermédiaire, sans pouvoir décisionnaire, dont l’objectif principal serait de servir d’interface entre les développeurs contributeurs et le mergeur des PR.

Ce rôle ne remplacerait évidemment pas le core dev / mergeur, mais viendrait lui simplifier le travail.

Missions possibles du consigliere

Concrètement, le consigliere pourrait :

  • analyser les PR en attente (contenu, qualité, impact),

  • contacter l’auteur de la PR si nécessaire (questions, demandes de modifications, tests manquants),

  • apporter lui-même des correctifs sur la PR lorsque c’est pertinent (rebase, nettoyage, ajustements mineurs),

  • s’assurer que la PR est “merge-ready” avant de la proposer au mergeur,

  • faire le lien humain et technique entre contributeurs et mergeur.

L’objectif est simple :
:backhand_index_pointing_right: réduire au maximum le temps et l’effort nécessaires au merge final.

Charge de travail

Ce rôle pourrait être cadré de manière très claire :

  • par exemple 1 jour par semaine,
    ou

  • un quota de PR / issues traitées sur une période donnée (semaine ou mois).

Il ne s’agit donc pas d’un engagement à temps plein, mais d’un rôle borné et maîtrisé.

Extension possible côté issues / financement

Autre piste intéressante :
Le consigliere pourrait également :

  • proposer à des développeurs volontaires de travailler sur certaines issues,

  • après avoir contacté l’initiateur de l’issue,

  • en lui proposant :

    • soit un don à l’association Dolibarr,

    • soit (et surtout) un don direct au développeur qui prendra en charge l’issue.

Cela permettrait :

  • d’accélérer la résolution de certaines issues,

  • de valoriser le travail des développeurs,

  • et d’offrir à ceux qui le souhaitent une petite rémunération régulière, même modeste, mais motivante.

Objectif global

Ce rôle de consigliere aurait pour but :

  • de fluidifier la gestion GitHub,

  • d’améliorer l’expérience contributeur,

  • de désengorger le mergeur,

  • et, à terme, de réduire significativement le backlog PR / issues.

Ce post est avant tout une ouverture de discussion :

  • Est-ce que ce rôle vous semble pertinent ?

  • Voyez-vous des risques ou des points bloquants ?

  • Faut-il un seul consigliere ou plusieurs ?

  • Rôle temporaire, tournant, ou pérenne ?

Merci d’avance pour vos retours, avis et contre-propositions.

2

Hello,

Ce serait hyper bien ! Mais je pense que sans rémunération du consigliere, on va avoir de la peine à trouver des volontaires…

J’ai un peu envie de proposer un système de bounties avec un pourcentage pour les concigliere.

A plus

3

Hello,

le problème n’est il pas là ?

Avec plusieurs personnes qui pourraient merger les PR il n’y aurait pas besoin d’inventer des rôles supplémentaires.

4

Il me semble qu’il y a déjà plusieurs personnes qui mergent (ne serait-ce que sur les branches annexes).

Ajouter plusieurs mergeurs est une autre approche, mais elle pose aussi des questions de cohérence, de confiance et de responsabilité à long terme.

Le rôle de consigliere est une solution plus légère, réversible, et sans impact sur l’autorité technique finale et qui sait ouvrir la porte ensuite à prendre la responsabilité du merge.

Après quelques recherche il semble qu’il y ai d’autres titre moins “coloré” que consigliere à savoir “triage”, “reviewer” voir “contribution manager”.

5

Hello,
c’est à peu près le même constat auquel nous arrivons avec Lionel (pour rappel nous sommes 2 à partager la charge de la revue de code et d’acceptation des MR/PR sur la branche 18.0 LTS de dolibarr).

Avec ma petite expérience sur ce sujet je pense qu’il faut être passé par le rôle de mergeur pour comprendre et s’imprégner des subtilités qui ne sont pas évidentes dans ce domaine.

Par exemple la grande patience de @eldy à notre encontre et la mise à jour régulière de la documentation visant à définir ce qui pour lui était évident et été à mon sens une grande contribution (encore assez invisible) au projet lié à notre implication dans ce rôle.

Exemple RoadMap — Dolibarr ERP CRM Wiki

Un compte rendu de notre activité sur 2025 est en cours pour vous expliquer tout ça et ton message va clairement dans ce sens: améliorer la fluidité entre le moment où la PR arrive et le moment ou la PR est intégrée.

Le plus compliqué c’est l’espace-temps :

  • l’espace car nous sommes physiquement loin (ou très proches) ainsi une PR proposée par un membre de l’équipe de Lionel pourrait laisser croire que ça soit plus fluide si la machine à café est en activité (le développeur qui remonte la PR peut expliquer sur le coin de la table à Lionel le bug, et éventuellement lui montrer sur son pc) … ce qui n’est pas le cas quand on est loin, de ce fait il faut lorsqu’on créé une PR ajouter des tonnes de détails pour que le mergeur puisse se mettre dans la situation de reproduire le bug. Dans les faits Lionel est encore plus intransigeant avec les PR issues de son équipe pour justement ne pas donner l’impression d’accepter tout ce que son équipe propose !
  • le temps maintenant : entre le moment où le développeur envoi sa PR et le moment où le mergeur est disponible pour l’étudier … provoque le fait que le développeur est passé à autre chose, il a « changé de contexte » résultat s’il n’a pas donné assez de détails pour que le mergeur puisse reproduire la situation / le bug qu’il corrige / améliore avec sa PR le mergeur va lui demander des infos complémentaires et ça sera « trop tard » : le développeur est sur un autre bug, un autre projet, si ça se trouve il n’a plus accès à la race-condition qui a amenée au bug (s’il était chez un client par exemple)

On en parle à chaque fois aux devcamp, vous pouvez réécouter notre présentation sur le sujet, l’ajout de nouveaux mergeurs apporte des plus et des moins. Globalement je suis persuadé que ça apporte bien plus de choses positives que négatives. Les apprentis mergeurs deviennent en fait des « ambassadeurs » auprès des développeurs et comme nous sommes plus nombreux à « refuser » une PR ça éviter une cristallisation « individuelle » du genre :sob: « eldy refuse toujours mes pr » je suis le mal aimé.

Demain matin nous devrions boucler notre bilan 2025 de « mergeurs dolibarr 18.0 LTS » et tout ceci sera expliqué.

a+
Éric

6

Cela confirme mon intuition qu’il ne s’agit pas d’un problème de mergeur mais bien de communication (une fois de plus …).

Dans ma vision des choses, ce n’est pas un problème de refus mais plus un souci d’empilement, on traite la dernière PR qui vient de sortir mais et on laisse pourrir les plus anciennes.

Ce que me semble manquer c’est un moyen de remonter les “cold cases” ou de les enterrer définitivement.

7

Je vois passer quelques infos sur ce thread qui me semble bon d’amendé par mon point de vue. Comme de mauvaises métriques ne peuvent pas aboutir à de bonnes évolutions, voici quelques info qu’il semble important de rappeler (bien que déjà communiqués à de nombreuses reprises).

Le première est une correction à apporter, sur le fait que les PR ouvertes serait fermées automatiquement apres 1 an. Aucune PR n’a jamais été fermée automatiquement depuis la creation du projet (il n’y a aucun mécanisme automatique pour cela sur les PR). Mais ceci est bien vrai pour les issues (bugs ou feature request) sans interaction ni réponses. Elles le sont via une action github. La fermeture des PR par contre, a tjs été faite qd il y a defaut de reponses de l’auteur après retour de la ci ou du mergeur, ou que la PR est jugée obsolete ou non conforme (traité par une autre, en conflit avec une autre,…). Les cas sans reponse (CI ok + pas de tags de reponses sont rarrissime et très loin des 300 pr ouvertes, moins d’une vingtaine sur les 26000 reçus. Avoir 300 PR ouvertes n’est donc pas un problème tant que les non réponses sont limités à une vingtaine, mais plutôt un signe de forte contributions)

Il y aurait une grosse charge de travail de ma part sur les merge ? Non. Je le dit et repete, la validation des PR représente moins d’une demi journée de travail par semaine de ma part (si on concentre tout au même moment), et encore en exagerant.
Qd il m arrive d’etre surchargé sur le projet Dolibarr, c’ est pour corriger les bugs durant les beta, étant epaulés sur ce point que par 3 ou 4 contributeurs, mais en 20 ans, jamais je n’ai été en surcharge sur la validation de PR (et il y a encore pas mal de marge de sécurité). Cela peut être un SPOF, mais n’a jamais été un goulot d’étranglement.

Remarque sur le taux de refus de PR. Près de 95% des pr soumises sur develop sont mergés (voir detail sur github), soit l’un des taux de merge les plus elevé qu’un projet open source de la taille de Dolibarr puisse avoir (rappel des taux pour odoo et erpnext analysés il y a quelques années, de memoire, 50% et 80%). Et les 5% restant sur Dolibarr sont presques tous du au fait que les PR ne passent pas l’integration continue (donc non qualifiable) ou soumise sur la mauvaise branche.
Restons humble, ce taux me semble bien trop proche des 100% pour essayer de l’augmenter sans être utopique.

Les délai de réponse des PR ? Cela peut se constater sur la branche 18 pour laquelle les traitement a 3 mergeurs s’averent plus complexe mais ce n’est aucunement question de sous nombre selon moi, mais plutot le contraire: un probleme de surnombre de mergeur sur une meme branche. Le fait d’etre 3 au lieu de 1, pour des raisons experimentales et de transfert de competence, ne peut offrir les meme delais que la branche develop. Je préconise plutot de réduire à 1 ou 2 mergeur par branche au lieu de 3 pour reduire les delais, meme si c’est contre intuitif.
Sur develop par contre, 99% des pr encore ouvertes le restent car sont en attente de correction par l’auteur du defaut, ou en attente de creation de la branche freeze (pending). Je rappelle qu’une Integration continue en rouge est une PR qui requiert action de l’auteur, il n y aura presque jamais d’ action du mergeur dans ce cas, son role n’étant pas de finir un dev incomplet. Sans action, la PR sera laissée en l’etat (cas de la majorité des pr ouvertes… pour fermeture manuelle apres un long delai sans correction). La reponse de la CI sur une PR intervient, depuis 1 an, 20mn apres soumission (nous etions a 1h il y a 5 ans). Et si la CI est ok, le délai de réponse des PR sur la branche develop, a savoir le délai pour avoir le flag indiquant le motif de non merge (fix a faire, mauvaise branche, pr a decouper, en attente de reponse a une question, etc…), est de 1 semaine. Sur cette branche develop donc, espérer reduire le delai semble lui aussi utopique. Dans un mode de travail collaboratif, il ne me semble d’ailleurs pas souhaitable de faire moins si on veut que chacun puisse y mettre ces remarques ou suggestion avant merge, c’est déja un delai moyen trop bas.

Je rappelle donc où sont les goulots d’etranglement de mon point de vue :
Le traitement des issues (fermeture des issues ouvertes qui ont insufissement de fixeurs pour suivre le rythme des pr soumises/validées surtout en phase beta), le traitement des issues, le traitement des issues, et enfin le traitement des issues (principallement durant la phase beta).

Voila la vrai priorité, même si la situation actuelle permet déjà d’avoir un rythme d’évolution supérieure à beaucoup de projets, et même si elle a tendance à s’ameliorer sous l’effet de la réduction de la dette technique (le taux d’issues ouvertes de type bugs s’étant stabilisé, voir meme diminue depuis 2 ans), cela reste le maillon faible qui empechera demain de valider plus de PR si le rythme de PR soumises venait à encore augmenter (non par manque capacité de merger insuffisante, mais par necessité de mettre des quotas aux merge pour absorber les instabilités, difficile à corriger durant les beta qd le nombre de pr mergées est trop important).

Donc si il doit y avoir un role de consiglière (mais d’où vient ce terme ?), ce serait bienvenu je pense, mais ne serait pas sur les PR mais, selon moi, uniquement sur les Issues et leur traitement (analyse de leur non obsolécence sur la dernière version, relance de l’auteur, demande de copie écran pour comprendre, …).

9

Le Parrain, Tom Hagen est le consigliere de Don Corleone.

10

Sérieux @eldy, tu n’avais pas la ref? bon le terme était un peu putaclick je l’avoue mais quand même.

Je comprends bien que, d’un point de vue opérationnel, les PR ouvertes ne constituent pas un goulot d’étranglement et que la priorité se situe davantage sur le traitement des issues, notamment en phase beta. Cela rejoint d’ailleurs plusieurs retours que j’ai pu avoir ces dernières années. Je sais aussi que la grande majorité de mes PR passent crême.

Mais il faut considérer la perception externe du nombre de PR et Issue ouverte, en particulier pour les nouveaux contributeurs ou les développeurs qui découvrent le dépôt GitHub. cela peut donner l’impression d’un backlog difficile à suivre, même si, en pratique, le flux fonctionne correctement.

Un travail de triage régulier aurait donc un intérêt en termes de lisibilité et d’expérience contributeur, en complément de l’aspect purement technique et apporterait sans doute une touche plus “humaine” et dans l’esprit “libriste” de notre projet.

11

En réalité il n’y a actuellement que 349 issues qui sont classées BUG, qui ne sont affectées à personne et qui ne font pas déjà l’objet d’une PR

Capture d’écran du 2026-02-05 09-25-01
Capture d’écran du 2026-02-05 09-25-01552×142 9.61 KB

12

Oui, cependant l’image perçu est la présence de 900 issues et il est tres probable qu’un simple contact avec la personne à l’origine du pr ou de l’issue règlerait le souci dans 80% des cas (dois préciser la ref?) et c’est là que le consigliere aurait tout son role.

13

Puisqu’on parle d’issues, il y en a une que j’aimerais bien voir corrigée

14

Bonjour,
J’avoue que j’essaie de contribuer plus depuis quelque temps, et que le CI-phan - même si j’en perçois bien tout l’intérêt - a tendance à me rendre fou
Eldy : Je rappelle qu’une Integration continue en rouge est une PR qui requiert action de l’auteur, il n y aura presque jamais d’ action du mergeur dans ce cas, son role n’étant pas de finir un dev incomplet
Désolé, je ne suis peut-être pas au niveau, mais il arrive (très) souvent que le CI soit en rouge mais que cela ne provienne pas des modifs effectuées dans le PR

Ici un PR avec un CI en rouge qui n’a touché qu’à un seul fichier (/core/modules/facture/doc/pdf_octopus.modules.php)

Phanshit
Phanshit1797×429 88 KB

Et si parfois l’erreur CI-Phan apparait dans les fichiers modifiés, ici rien
Avoir un “consigliere” qui explique des choses comme ça serait cool … et permettrait de redonner foi et courage en la contribution, car j’avoue qu’elle commence à s’émousser :wink:

15

Le problème vient du fait que ton fork de dolibarr a été fait depuis le commit d02dfe0 et que sur ce commit phan échoue comme on peut le voir ci-dessous

Capture d’écran du 2026-02-05 11-34-54
Capture d’écran du 2026-02-05 11-34-54513×239 14.2 KB

Donc le code de ta PR étant basé sur du code qui fait échouer phan va forcément échouer à son tour.

Pour corriger il faut synchroniser ta branche Fix_VAT_Octopus_33521 avec le dépôt dolibarr, et ensuite faire un force push sur ta PR pour écraser l’ancien code.
Les tests vont être relancés et devraient passer (si ta synchronisation s’est faite depuis une version du dépôt dolibarr qui n’a pas de problèmes à ce niveau là bien sûr - ce qui n’est pas le cas actuellement sur le dernier commit de la branche develop).

Le problème de base c’est qu’il y a des commits qui sont faits sur le dépôt sans passer par des PR, et certains commit font planter la CI. Du coup par cascade toutes les PR qui partent de cette version plantogène vont planter à leur tour.

Si on veut faciliter le travail des développeurs il faut arrêter de faire des commits avec du code qui fait planter la CI.

16

et c’est là que quelqu’un expliquant ce genre de chose prend du sens

17

Bonjour,

j’avais essayé d’avoir des infos sur une issue à ce sujet.

Malheureusement pas d’infos à ce jour.

18

Merci de ces explications, je pense avoir compris, je merge régulièrement ma branche en cours de PR avec la branche develop, et ai effectivement constaté que le merge “re”plantait parfois la CI qui ne l’était pas avant ..
Bon ils ne sont pas nombreux ceux qui peuvent commiter sans passer par un PR :wink:

19

Comme je suis en train de travailler sur le suivi des contributions dans github

je vous partage un tests sur les volumétries des pr par date de création :

Pour les PR

mois en cours : 48
trimestre en cours : 108
année en cours : 198
Période précédente : 96

Pour les Issues

CurrentMonth : 46
CurrentQuarter : 139
CurrentYear : 595
Période précédente : 271

20

Non. Je regarde que les films où les héros sont les gentils !

21

Hélas le pb est dans l’outil doxygen, et non dans dolibarr. Doxygen génère un code buggué pour la partie recherche. Je n’ai pas réussi à trouver de fix.