Salut,
C’est effectivement une bonne idée, mais il faudrait arriver à motiver @jtraulle sur le sujet.
En effet, quelque soit l’outil, on constate que pour obtenir des interactions, il vaut mieux poser du concret plutôt que de l’idée. Et qu’il vaut mieux utiliser l’outil dédié à cela, donc, pour de la proposition de modification de code, d’utiliser les PR (je sais je radote, mais comme j’ai du mal à me faire comprendre, je répète à nouveau).
Les autres développeurs n’hésitent pas à proposer des PR pour des changements et évolutions structurante ou douteuse dans le core, souvent en Draft quand le code n’est qu’à l’état d’expérimentation (cela s’appelle du prototypage, et le prototypage est indispensable dans toute évolution d’architecture).
Le concret rend aussi les discussions plus faciles et permet à chacun de voir de manière moins abstraite la proposition, permettant de mieux estimer l’impact que cela aura sur l’existant, sur les modules externes, de savoir de suite ce que cela casse grâce au résultat de la CTI, d’estimer le coût de la généralisation du proto à l’ensemble du coeur, et de se faire une idée des étapes pour y arriver.
Certains développeurs vont jusqu’à faire une PR draft par étape à franchir (quitte à détruire leur PR draft et la refaire différemment plus tard). Cette pratique de draft par étape est une très bonne pratique, car une idée n’est souvent pas suffisante, il faut aussi voir comment attendre l’objectif porté par l’idée au final. C’est ainsi qu’on peut évaluer l’impact d’une évol d’archi. Sans cela, même sur un projet avec beaucoup de contributeurs, on constate que les retours sur une évolution d’architecture restent, soit faible, soit trop vagues pour être constructif. Ceci n’a rien de surprenant.
Les issues sont plus utilisés pour déclarer les bugs (d’où le nom « Issue ») ou demande de fonctionnalités au sens utilisateur (D’où le nom « feature request ») que pour faire des draft des propositions d’évolutions (ce sont plutôt les PR, en draft, ou final si le proto est au point, pour cela).
Hmmmm au risque de s’éloigner du sujet de ce fil, autre exemple de PR « draft » donc : 18.0 fix links error on dedicated virtualhost and ticket code review by rycks · Pull Request #28446 · Dolibarr/dolibarr · GitHub je n’ai pas non plus vu passer beaucoup de commentaires et surtout je « craint » qu’elle ne se trouve maintenant « trop loin » dans le flux des PR pour qu’elle ait une chance d’être acceptée / validée
Autre exemple pour une PR qui m’intéresse beaucoup plus : je ne participe pas sur github qui me semble trop impersonnel … add extrafield point by frederic34 · Pull Request #28239 · Dolibarr/dolibarr · GitHub ce n’est pas un lieu pour échanger entre humain, c’est une suite de messages automatiques de git bidule git commit et autres informations importantes mais qui n’invitent pas à s’exprimer
nous avons des avis différents sur la question, pour ma part lorsque j’ai besoin de bavarder entre humain avant de lancer une implémentation technique le bon outil c’est le coin de la table, la machine à café, un paperboard, des crayons, des feutres, des post-it …et la version « online » déjà bien moins agréable (au sens nombre de dispositifs permettant d’illustrer ses propos) c’est le forum … ensuite loin après vient l’outil du dev pour moi. Concevoir une solution c’est réfléchir, faire des dessins, collecter des informations, laisser décanter, bavarder à plusieurs, opposer des idées, confronter des points de vues etc.
Tiens, regarde durant un devcamp le temps qu’on passe à coder par rapport au temps qu’on passe à échanger et au final c’est quoi le plus important de ces momens là ? 
Bonjour,
Les raisons qui font que c’est séparé ont déjà été exposées précédemment.
Personnellement, outre le fait que je ne suis absolument pas convaincu que cela apporterait un quelconque bénéfice, l’investissement en temps pour réaliser ce genre de modification est lourd et je n’ai malheureusement pas de temps à consacrer à cela.
Voir également la réponse de @eldy plus bas qui résume selon moi parfaitement bien ma façon de voir les choses 
C’est totalement compréhensible.
Cependant il y a a peut-être d’autres personnes qui ont les compétences nécessaires pour faire cela. N’est-ce pas le principe même d’un projet open source de permettre à tout un chacun de participer à l’effort ?
1 « J'aime »
Totalement, et je n’empêche personne de proposer ou de travailler sur quoi que ce soit mais je ne gère pas le projet et ce n’est pas moi qui décide de tout de façons de réaliser ou non une fusion des forums des différentes langues en un seul.
Il me semble que ce type de modification profonde au niveau du projet doit se décider au niveau de l’association Association Dolibarr - Dolibarr ERP CRM Wiki par le @ca-asso.
Par ailleurs, il me semble que certaines communautés Dolibarr ne souhaitent de tout de façon pas voir leur forum fusionné en un seul.
Merci pour ces précisions.
un exemple vraiment concret d’une PR avec un échange qui finalement ne sert à rien d’après moi : codespell and datee by rycks · Pull Request #28828 · Dolibarr/dolibarr · GitHub
Question dans l’assemblée qui arrive à voir le contenu des échanges qu’il y a eu ? je n’arrive même plus à déplier le bidule pour voir les 9 échanges de la conversation alors que j’étais partie prenante…
ces échanges deviennent invisibles, inaccessibles, non indexés par un moteur de recherche (interne à github / au projet ou plus large du genre goo***) … bref pour moi c’est l’archétype du truc qui sert à rien dans le sens partage de l’information et « pédagogie » sur le projet
peut-être que je me trompe mais je pense vraiment que cette PR va mourir et disparaître, il n’en restera rien et le temps passé à son sujet ne servira probablement à personne d’autre alors que les échanges qu’il y a eu à son sujet pourraient servir à d’autres développeurs qui vont se heurter comme moi à codespell qui débarque sur develop et qui interdit certains commit (en tout cas c’est ce que j’ai vécu ce matin et qui m’a fait perdre 30 minutes et provoquer cette PR finalement refusée car « peut mieux faire » 
)
Note: j’ai mis 10 minutes à trouver qu’il faut cliquer sur « show resolved » pour déplier les échanges … vraiment une fois qu’on le sait c’est « évident » …
1 « J'aime »
Bonsoir,
concrètement voilà ce que je vais proposer d’ici peu:
je ne sais pas si je vais avoir le temps de rajouter la notion de middleware au passage et faire en sorte que le routeur soit un objet et non une fonction « plate » … mais bon en tout cas ça me semble assez propre pour construire sur ce genre de concept.
pour info le AuthController ne fait que vérifier les objets User de dolibarr avec login/pass et génère un JWT (token) pour l’application, sans plus pour l’instant.
Et les autres contrôleurs par exemple MenuController est là pour piloter ce qui s’affiche sur l’interface du smartphone (page d’accueil / le menu)…
DlcController lui fait le passe-plat entre l’api json CRUD pour smartphone et les objets dolibarr. Pour ne pas perdre en route les développeurs d’applications je me suis calé sur les habitudes structurantes de laravel dans laquelle on trouve par exemple ceci:
PSR-4 is done sur cette partie en tout cas, vous voulez offrir un nouvel objet à votre application smartphone ? il faudra créer un controleur comme ceci:
Et ensuite définir les points d’entrées que vous voulez dans le fichier api.php
3 « J'aime »
Point d’étape avec le cas concret de l’application SmartDLC :
En résumé: il y a une api spécifique entre l’application smartphone et le serveur, cette API est implémentée « dans l’idée » de Laravel, j’espère ne pas avoir trop dénaturé cette approche d’ailleurs … et ensuite cette API fait du « collage » avec le code dolibarr
Normalement nous nous lançons sur le redev de SmartLivraison (@mi973 c’est pour toi entre autre) pour basculer sur cette pile technologique …les résultats devraient être sans comparaison avec mes précédents itérations …
1 « J'aime »
