Journal The Minimum Viable Pull-request

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
-2
7
nov.
2018

Bon Jour Nal, j'ai une petite confession pour toi.

Pendant de nombreuses années j'ai été un croyant non pratiquant en matière de logiciel libre.

Les idées du logiciel libre m'ont convaincu assez rapidement et depuis longtemps.
Par contre, contribuer à pleins de projets ici et là? Voire lancer mes propres projets libre? Ben euh, pas vraiment…
Ce n'est pas que j'ai jamais essayé, mais le plus souvent j'ai ressenti l'expérience comme en pratique assez frustrante.

Et puis récemment les choses ont changé. J'ai compris clairement quelque-chose de simple. Quelque-chose de sans doute évident pour tous ceux qui contribuent beaucoup au libre, mais qu'il ne l'était pas pour moi. Un nouveau projet, open source ou pas, est surtout un projet dont on connait en réalité très peu de choses. La priorité d'une première contribution Open Source n'est donc pas le code, mais d'établir au plus vite la communication avec les mainteneurs du projet.

Je décris ça dans mon article en anglais The Minimum Viable Pull-Request

  • # Un peu mieux qu'une redirection

    Posté par  (site web personnel) . Évalué à 10.

    C'est alléchant. Sauf que j'ai la flemme de lire en anglais quand je viens sur Linuxfr (c'est le "fr", ça me fait cet effet là). Ton journal gagnerait soit à pointer vers un article en français (encore que, rédigé comme ça, ça fait un peu réclame), soit à enrichir le lien en nous proposant ici la traduction. Ou au moins un résumé. Mais peut-être que tout est résumé dans cette phrase :

    La priorité d'une première contribution Open Source n'est donc pas le code, mais d'établir au plus vite la communication avec les mainteneurs du projet.

    Si c'est le cas, désolé pour le bruit :)

  • # "WIP"

    Posté par  . Évalué à 0.

    Une information qui n'a été accessible que via une recherche : WIP = Work in Progress.

    • [^] # Re: "WIP"

      Posté par  . Évalué à -1. Dernière modification le 07 novembre 2018 à 17:29.

      Oui, WIP == Work in Progress
      et WIP Pull Request c'est ca https://ben.straub.cc/2015/04/02/wip-pull-request/

    • [^] # Re: "WIP"

      Posté par  . Évalué à -1.

      Tu cherches à dire quoi, par la? T'as déjà vu un travail pas en progrès dans le libre toi? Me semble que, dans le libre, un travail pas en progrès, on appelle ça…. UN PROJET MORT!!!!

      • [^] # Re: "WIP"

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Que nenni : un projet WIP c'est un projet qui n'a pas publié de version jugée stable. Cette version peut être fonctionnellement très incomplète, mais ce qu'elle fait, ça marche et peut être mis en prod. Un WIP, c'est "bon, ça marche mal, ou que dans certains cas bien particuliers, c'est pas à mettre en prod".

      • [^] # Re: "WIP"

        Posté par  (site web personnel, Mastodon) . Évalué à 5.

        « Work In Progress » = « Travail en cours » et non « Travail en progrès ».

        La connaissance libre : https://zestedesavoir.com

        • [^] # Re: "WIP"

          Posté par  (Mastodon) . Évalué à 4.

          Oui, on pourrait presque traduire par "en travaux". Il suffit de chercher "work in progress" en images sur un moteur de recherche pour voir la dominante jaune "chantier".

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Requête de tirage

    Posté par  (site web personnel) . Évalué à 2.

    Je préfère dire ça comme ça, je trouve que c'est plus poétique.

    • [^] # Re: Requête de tirage

      Posté par  (site web personnel) . Évalué à 4.

      demande d’intégration

      Un pull c’est un fetch et un merge. Le tirage c’est juste le fetch. Le mot intégration fonctionne aussi bien pour l’idée d’une fusion (merge) et pour l’idée d’une fusion après récupération (merge after fetch i.e. pull). Le terme requête est juste mais peut-être un peu trop soutenu.

      Le mot « tirage » s’il est bien français n’est simplement jamais utilisé pour une fusion ou une récupération, donc c’est vraiment un anglicisme ici. On ne dit pas « je vais aller tirer mon colis » en allant à la poste pour dire qu’on va le récupérer, « se faire tirer son colis » a vraiment un tout autre sens.

      ce commentaire est sous licence cc by 4 et précédentes

  • # "spam"

    Posté par  . Évalué à -6.

    Je vois que mon journal est tagué: "spam", "seo", "postdu1erjour".
    Comme indiqué dans un commentaire précédent, j'ai participé à ce site pendant de nombreux années sous un autre compte que j'ai fermé un jour qu'aujourd'hui.
    À l'époque Linuxfr était déjà aussi bienveillant avec les nouveaux venus.
    Quelque part, c'est drôle de voir que certaines choses ne changent pas.
    Désolé d'avoir dérangé votre entre-soi en voulant partager mon retour d'expérience.

    • [^] # Re: "spam"

      Posté par  . Évalué à 10.

      Y a plein de personne qui postent des articles tirés de leur blog ici (le Bortz par exemple). Par contre ils font l’effort d’apporter du contenu et pas simplement de poster un lien vers un article en anglais (rappel, DLFP est sur un site francophone).

      • [^] # Re: "spam"

        Posté par  . Évalué à -6.

        J'écris maintenant par défaut en anglais parce que j'habite à l'étranger et que écrire pour un public de 0 à 2 lecteurs ne serait pas trop motivant :)

        Mais oui j'ai merdé et j'aurais dû notamment penser à une traduction française du titre qui me convienne (même maintenant j'en ai pas vraiment, c'est le concept de MVP qui exprime le plus précisément mon idée).

        Mais bon, ce qui est fait est fait.

        • [^] # Re: "spam"

          Posté par  (site web personnel) . Évalué à 10.

          Si c’était un public de 0 à 2 lecteurs ce ne serait même pas la peine de poster le lien. ;-)

          Indice : le nombre de lecteurs avec un lien posté ici dépend… de sa langue française, c’est donc l’écriture en français qui serait cause de l’augmentation du nombre de lecteurs au delà de 2. ;-)

          ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: "spam"

          Posté par  . Évalué à 9. Dernière modification le 08 novembre 2018 à 15:50.

          J'écris maintenant par défaut en anglais parce que j'habite à l'étranger et que écrire pour un public de 0 à 2 lecteurs ne serait pas trop motivant :)

          J’habite aussi à "l’étranger" (enfin je suppose, je n’habite pas en France en tout cas) et j’écris aussi "par défaut en anglais", c’est pas le problème.

          Ce qu’il manque à ton journal c’est pas un lien vers un article en français. C’est du contenu (en français) autours de ce lien.

    • [^] # Re: "spam"

      Posté par  (site web personnel) . Évalué à 7. Dernière modification le 07 novembre 2018 à 20:09.

      Ne pas faire de généralités à partir de tags posés par un seul compte.

      Sinon le tag 'spam' est ici abusif par rapport à l'utilisation habituel ici, à savoir soit réellement parler de solutions anti-spam, soit signaler aux modérateurs un bon gros spam (souvent anglophones) car ce tag est surveillé. J'ai fait sauter les tags spam et seo sur ce journal du coup (le dernier tag étant masqué mais toujours présent).

      • [^] # Re: "spam"

        Posté par  . Évalué à 1.

        Compris. Et merci!

      • [^] # Re: "spam"

        Posté par  (Mastodon) . Évalué à 10.

        Ne pas faire de généralités à partir de tags posés par un seul compte.

        Je bats ma culpe, c'est moi.

        Mais bon, poster ici qu'on a écrit un article de blog en anglais avec un compte nouveau, c'est vraiment pas malin.

        J'explique mon raisonnement :
        - putain je comprends rien à ce journal, il veut dire quoi le mec ?
        - merde, faut que je lise son article pour comprendre
        - en anglais ? si son site pro ?
        - il a créé son compte aujourd'hui ou quoi ?

        lui, il veut se faire sa pub pour son site pro => spam

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: "spam"

      Posté par  . Évalué à 3. Dernière modification le 07 novembre 2018 à 22:08.

      Quelque part, c'est drôle de voir que certaines choses ne changent pas.
      Désolé d'avoir dérangé votre entre-soi en voulant partager mon retour d'expérience.

      Ho, ça va hein, linuxfr est peuplé entre autres de gens normaux, qui votent par la forme, pas par le fond.
      Et il est clair que ta forme est merdique, 3 lignes pour un article aussi intéressant en anglais… Tu aurais clairement pu faire un synopsis plus intéressant. D'un autre côté, je préfère 100 fois ça à un vulgaire lien, lierait-il à un article en français!

      Si t'avais juste voulu de la pub, t'aurais posté un lien, et tu n'aurais que peu été exposé à la vindicte. Tu as eu le courage de faire un journal, et certes la forme manque, mais à lire en diagonale, j'ai eu la sensation que le journal (et le lien) était sincère, même s'il ne semble rien apporter de neuf.

      Ce que tu tu aurais pu faire, pour te faire moins massacrer, c'est résumer, au lieu de juste sortir une phrase d'attaque traduite.

      • [^] # Re: "spam"

        Posté par  (site web personnel) . Évalué à 8.

        Quant à y aller de son petit conseil, voici le mien : dans l'article en Anglais il serait bon de donner la forme longue des acronymes employés étant donné le public visé : Peut-être s'agit-il d’abréviations que tout développeur utilisant git connaisse — quoi que j'ai un doute ; mais il paraît vraisemblable que le développeur débutant potentiellement intéressé par ces conseils n'ait pas la plus traitre idée de leur signification.

        Sur le fond, il me semble que je risque bien de mettre en pratique prochainement le contenu de cet article. Merci.

        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # J'ai lu, je ne suis pas d'accord

    Posté par  (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 08 novembre 2018 à 13:16.

    Sommaire

    Bon, comme quoi ça sert d'avoir tous ces commentaires pour te dire que c'est pas une bonne présentation: je prévoyais absolument pas de lire (je ne sais pas si c'est la présentation, ou juste le fait que je lis rarement ce types d'articles), mais en lisant les commentaires ici, j'ai décidé de jeter un œil à ton essai.

    Bon ben je ne suis pas d'accord avec les prémisses du problèmes, ni avec les "solutions".

    Prémisses du problème

    So just fork the project, write the feature, propose it, done.

    Done? No!

    This lone cowboy approach is a recipe for frustration!

    Ben… si. Ce que tu appelles cette approche "cowboy solitaire", c'est exactement ce qu'il faut faire selon moi. Je pense que tu compliques en sur-pensant un problème simple.
    Et la raison pour cela est (j'ai l'impression) que tu ne contribues peut-être pas pour les bonnes raisons. Tu dis jamais vraiment pour quoi tu contribues, alors je vais supposer (peut-être à tort) que tu contribues pour contribuer car plus tard, quand tu parles de ton cas concret avec ton plugin gradle, tu expliques que tu as ouvert des pull requests dans divers projets pour leur faire utiliser. En fait donc rien n'allait pas bien dans ces projets hormis le fait qu'ils n'utilisaient pas ton plugin?!

    En fait, le "pourquoi on contribue" est tout simplement LA source des contributions. Faut pas chercher plus loin. Tu parles de ses "Rock-Star Ninja Developers". Aucun ne se pose le type de questions que tu poses (et tous emploient l'approche que tu as nommé "cowboy solitaire"). Ils savent juste pourquoi ils contribuent. Certains, car c'est leur boulot. D'autres car c'est leur projet perso. Beaucoup, comme moi, car on utilise et simplement on a des bugs ou on veut des fonctionnalités. Énormément de développeurs viennent nous voir chez GIMP avec comme premier message "Je veux contribuer à GIMP, vous pouvez me dire sur quoi je peux coder?". Déjà ça part super mal. Tellement mal que je n'ai pas vu UN SEUL contributeur de ce type qui a réellement fourni un patch au final, de mémoire.
    Un contributeur qui donne quelque chose de concret est uniquement les dits "cowboys solitaires" qui ont un besoin, le patche et fournissent le patch. Simple.
    Ceux là, on en voit régulièrement dans GIMP. Bien sûr, des fois on discute la fonctionnalité ou son implémentation, mais en général on arrive à une solution.

    Pourquoi? Parce que déjà si la fonctionnalité (ou la correction de bug) était nécessaire pour cette personne, y a de grandes chances que ça le soit pour d'autres, donc les chances de la voir acceptée est grande aussi. En plus elle sera probablement mieux codée car la personne l'utilise vraiment (et donc verra les bugs oubliés).
    Personnellement c'est bien simple, de ma vie, je n'ai contribué que pour des choses qui m'étaient nécessaires. Et encore j'arrive pas à tout faire. Si je pouvais physiquement faire plus, j'ai 1000 autres patchs à créer à 100 autres projets! Alors je comprends pas les gens qui posent la question "que faire?" qui mène à la question "comment contribuer à un projet libre?". Qui n'a jamais eu un bug ou un crash d'un logiciel qu'on utilise beaucoup? Qui n'a jamais pensé "Ah ce serait cool si je pouvais faire ça"?
    C'est bien simple, le jour où tu auras un besoin, aucune de ses questions ne se posera plus. Tu corrigeras pour toi et tu enverras le patch. Et c'est bien tout!

    Comment contribuer?

    Bon maintenant que j'ai établi que les prémisses sont problématiques et que la question qui est la base du reste de la discussion est la mauvaise, on pourrait arrêter là. Mais soit, admettons qu'on veuille quand même poser cette question étrange: comment contribuer?

    Les problèmes?…

    Les problèmes cités sont:

    The project is not maintained anymore.

    Bon ça peut arriver. Tu peux regarder les logs et si y a rien depuis longtemps, on peut se poser des questions (même si ça veut juste dire qu'y a pas de développement actif, mais il peut y avoir maintenance minimale quand même). Ensuite est-ce grave? Comme je l'ai dit, la prémisse est mauvaise si tu contribues sans avoir besoin. Si c'est pour juste histoire d'avoir ton nom dans une liste de gens, bon ça sert à rien de contribuer. Si tu utilises, ben tu fais ton patch, tu l'envoies quand même (sans grand espoir peut-être, mais une fois fait, autant envoyer; au pire ça servira peut-être à quelqu'un d'autres même si c'est jamais inclus), et tu utilises pour toi, tout content car tu as corrigé ou amélioré un logiciel que tu utilises!

    Éventuellement s'il s'agit d'un logiciel qui a un certain intérêt clair, tu peux en reprendre la maintenance. Je l'ai fait pour quelques logiciels, en général en mode "maintenance seulement". C'est à dire que je prends les patchs des gens, je les applique, je mets à jour le strict minimum pour le système de compilation au besoin. Travail minimum mais je m'arrange que le logiciel reste au moins utilisable, compilable et pas trop buggué (car, je répète: moi aussi j'utilise! Ou du moins j'utilisais quand j'ai contribué).
    Dans de tels cas, je serais d'ailleurs heureux de pouvoir en passer la maintenance à quelqu'un en gardant le code à flot jusqu'à ce que quelqu'un qui souhaite s'impliquer plus que moi débarque (par exemple je maintiens Tiny Segmenter de cette façon, où je fais en gros une release par an avec un unique patch que quelqu'un d'inconnu m'envoie de temps en temps).

    The maintainer is not interested, he has different goals than you.

    Ça arrive. C'est chiant surtout si tu veux vraiment cette fonctionnalité, et rien n'est pire que de maintenir ton fork perso juste pour toi. Mais bon, c'est la vie!
    Je fais plein de trucs tout le temps, et ça mène pas toujours à quelque chose de concret (je parle même pas de développement, mais dans ma vie en générale).

    There was a 5 times easier way to implement the same thing.
    […]

    Tous les autres problèmes cités sont juste des problèmes de développement. Je vois pas le problème du tout. Oui, il se peut qu'on te demande de revoir ton patch. Et alors? :-)
    On n'a jamais dit que le développement d'application était un truc facile et que l'implémentation de nouveau code se fait toujours en une fois. :P

    Franchement j'ai du mal à voir les problèmes dans ta liste!

    Solution?

    Alors là on est à un point où on est pas d'accord sur les prémisses, puis sur la liste de ce qui est ou non un problème. Donc je pense que ça sert à rien de continuer en citant aussi tes solutions (ton "MVP"). Mais il va sans dire que je crois absolument pas que ce soit une solution à quoi que ce soit.

    Attention je dis pas que ce que tu dis est mauvais et qu'il faut pas parler avec les mainteneurs d'un programme! Juste que clairement ce que tu sembles indiquer comme une sorte de recette magique n'en est absolument pas une selon moi.

    Bon allez, juste une citation quand même:

    Most importantly, obtain the permission for working on the change before you actually spend the time on it.

    Alors ça c'est super sensible. D'un côté, si ce que tu vas faire va te prendre beaucoup de temps (genre au moins 2 semaines à temps plein!), alors oui il vaut peut être mieux de s'assurer que ce sera intégré.

    Néanmoins ne disions nous pas qu'on développe aussi pour nous?! Si c'est une fonctionnalité que tu veux vraiment vraiment, est-ce vraiment perdu si tu peux au moins utiliser cela même si c'est refusé upstream? C'est pas une question réthorique, mais une vraie question à faire au cas par cas sur chaque projet. Je le disais plus haut, maintenir un fork perso quand le projet principal évolue beaucoup (et qu'on veut aussi bénéficier des évolutions) n'est pas quelque chose que je conseille à la légère. Mais dans certains cas, ça peut valoir le coup.

    Ensuite et si le développeur comprends mal ta proposition et refuse (alors qu'il aurait accepté en voyant le vrai patch)? Et s'il a trop de boulot et ne lit pas ton message avant 6 mois (quand tu as déjà abandonné depuis longtemps et es passé à autre chose)? Et si ça engage des discussions avec des trolls où on se met à faire du "bikeshedding" avant même que la moindre ligne de code utile soit produite?

    Perso je demande jamais, ou presque (en fait, quand je demande, c'est plus quand c'est vraiment pas prioritaire, que je sais que de toutes façons je le ferai pas tout de suite car je peux pas faire du temps pour ça, ou quand j'espère que quelqu'un d'autre me prendre l'idée que je mets par écrits et le fera avant moi). Je fais, j'envoie et j'oublie.
    Éventuellement si on me demande des changements, je reçois de toutes façons un email de notif, je reviens sur mon code quand je peux faire un peu de temps, je change, je pousse et oublie encore.

    Obtenir permission, c'est plus une perte de temps et de motivation qu'autre chose. Je suis plus en maternelle quand je demandais permission à la maîtresse pour tout et rien. Le pire qui puisse arriver, c'est que mon patch ne soit pas accepté. J'aurais alors utilisé quelques heures ou jours pendant lesquels je me suis cependant bien amusé à lire du code et le comprendre, et au final j'aurais un changement que je peux quand même utiliser moi-même (ce qui était le principal but, je le rappelle).

    Et ma "solution"?

    Allez pour ne pas laisser ce commentaire sur une note négative, je vais quand même laisser ma "méthode". Notez les guillemets car c'est un peu présomptueux de parler de solution ou de méthode. Je pense pas qu'une telle chose existe, et ça va dépendre des gens aussi.
    Mais voilà, ça se résume en 3 mots: persévérance, compréhension et bienveillance

    Persévérance

    Dans persévérance, on pourrait aussi mettre patience. De manière générale, ne pas s'attendre à une inclusion éclair d'un patch. Alors ça peut arriver, mais juste ne pas s'étonner quand ça n'arrive pas. Je le disais, c'est pour cela qu'en général je fais, j'envoie, j'oublie. Forcément si on reste devant sa boîte email à attendre une notification de réponse, ça ne peut être qu'une mauvaise expérience dans beaucoup de cas et on peut facilement se mettre à étiqueter un projet comme "non maintenu" même quand il l'est.

    Par contre il faut aussi savoir revenir sur un patch. En général je conseille d'attendre quelques mois. Genre si 2 ou 3 mois après un envoi de patch, il n'y a pas de réponse, alors faire une petite relance, poli et gentille. On sait jamais, le mainteneur a peut-être vu, puis a oublié. Ça arrive.

    Puis répéter, régulièrement, toujours agréablement et poliment. Note que je n'ai même pas besoin de garder une liste de mes patchs en attente, puisque j'utilise les choses que je patche, donc je m'en rappellerai forcément un jour (genre dans 2 mois, je lance tel programme et utilise telle fonctionnalité, et "tiens j'ai jamais eu de nouvelle de ce patch" vient tout seul).

    En fait dans les rares patchs que j'ai faits et qui n'ont pas été intégrés, certains sont parce que j'étais jeune et ne savais pas encore à l'époque qu'il fallait savoir insister un peu (je me souviens d'un de mes patchs pour une cool fonctionnalité sur mplayer par exemple; je n'avais jamais eu de réponse puis j'ai oublié même si j'ai moi-même utilisé mon patch pendant des années; de nos jours, dans mpv, la fonctionnalité que j'avais implémenté existe, implémentée par quelqu'un d'autre).

    Il n'y a pas de mal à insister un peu, du moment qu'on le fait agréablement (je me répète sur le côté poli/agréable, mais c'est important). Ça ne gêne personne ni n'est jamais mal pris.

    Compréhension

    Compréhension du problème bien sûr, ça c'est le boulot du développeur. Mais surtout compréhension des gens. Savoir ce qu'autrui veut, comprendre ce que l'autre dit et pourquoi il aime ou non, et essayer si possible de faire des compromis (pour éviter le problème du fork perso à maintenir) quand il apparaît que sa proposition initiale ne sera pas intégrée (du moins pas comme tel). "Discuter" (dans le contexte d'une discussion sur un patch), en général ça veut dire "comprendre ce que l'autre veut et comment faire pour qu'on ait tous les deux ce qu'on veut".

    Aussi comprendre l'humain et pourquoi quelqu'un ne répond pas vite par exemple. Ou bien ne pas prendre mal si on a l'impression de recevoir une réponse un peu sèche (peut-être l'était-elle, peut-être était-ce juste une incompréhension de l'écrit). La plupart des situations peuvent être désamorcées en essayant de comprendre autrui et de réagir de manière appropriée.
    En gros avoir de l'empathie.

    Bienveillance

    Ça peut sembler une répétition des 2 points précédents, et c'est vrai que tout se mêle un peu, mais c'est vraiment important alors ça mérite son propre point. Quoi qu'on fasse, essayer de le faire posément et avec bienveillance. C'est pas toujours facile. Il arrive à tous de se mettre en colère quand certains sont vraiment insupportables. Mais parfois se faire un peu violence et même avec les gens très désagréables, il faut essayer de rester poli. Dans tous les cas, rien ne viendra jamais d'une guerre ouverte et d'une dispute.

    Voilà. Donc avec ces quelques points bien respectés, non seulement tu te poseras même plus la question de "comment contribuer?" car ça viendra tout seul, mais en plus la plupart des patchs seront intégrés sans trop de problèmes. :-)

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: J'ai lu, je ne suis pas d'accord

      Posté par  . Évalué à 5. Dernière modification le 08 novembre 2018 à 18:37.

      Merci d'avoir pris la plume pour dire pourquoi tu n'étais pas d'accord, ça fait du bien un commentaire sur le fond!

      (Et ça me rappelle que Linuxfr a aussi plein de bons côtés et que c'est pour ça que j'y passais du temps!)

      Je ne vais tout reprendre, la lecture de ton commentaire se suffit à elle-même, mais tu as notamment tout à fait raison sur interroger le Pourquoi ? de ta motivation à contribuer avant toute chose. C'est un point essentiel que j'ai laissé à tort de côté en me concentrant sur le "Comment?".

      Sur le "Comment?" : je suis tout à fait d'accord sur ce que tu dis très bien dans tes sections Compréhension et Bienveillance. Ça rejoint (et améliore) mon point qui est que la communication est primordiale quand on s'adresse à des gens qu'au départ on ne connaît pas.

      Par contre je ne suis pas tout à fait d'accord sur la partie Persévérance. C'est une belle vertu, qu'il faut mieux économiser pour là où ça en vaut vraiment la peine. Le point c'est qu'à un moment donné il y a plein de projets où je peux potentiellement contribuer et je trouve important de choisir, de me concentrer sur là où je peux avoir un impact.

      Le cas de mon plugin Gradle est très particulier. Un exemple plus typique est cette première contribution que j'ai faite au projet Moshi (séralization JSON) pour rajouter une option prettyprint. J'avais bien conscience du "Pourquoi ?", mais aussi que cette fonctionnalité me serait utile mais pas primordiale. Donc l'efficacité de la contribution est décisive! Si je dois m'y reprendre à 10 fois avant que ma contribution ait un effet, mieux vaut faire un hack dans mon coin! Donc j'ai utilisé cette idée de juste rajouter un test qui montre ce que je me propose de faire. Puis j'ai engagé la conversation avec Jesse Wilson m'a guidé sur une meilleure API que ce que j'avais prévu, me donnant le signal que je pouvais y aller! Tout s'est passé de manière très fluide et je suis sorti content de cette expérience. Ce qui m'a donné envie de le faire plus souvent!

      References:

      • [^] # Re: J'ai lu, je ne suis pas d'accord

        Posté par  (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 08 novembre 2018 à 22:11.

        Hmm… j'ai relu mon commentaire et je vois que j'ai vraiment laissé passer plein de fautes (dont plusieurs vraiment embarrassant s/ses/ces/)! Je l'ai écrit d'une traite sans me relire, mais je pensais pas que ce serait si terrible. C'est ça de vieillir. :-/

        Par contre je ne suis pas tout à fait d'accord sur la partie Persévérance. C'est une belle vertu, qu'il faut mieux économiser pour là où ça en vaut vraiment la peine. Le point c'est qu'à un moment donné il y a plein de projets où je peux potentiellement contribuer et je trouve important de choisir, de me concentrer sur là où je peux avoir un impact.

        Ben justement tu choisis tes projets en fonction de ton besoin, pas de la situation qui fait qu'un projet sera peut-être plus complexe/long à gérer. Ou alors je sais pas trop comment tu gères tes priorités, mais c'est étrange pour moi.

        D'après moi le point de persévérance est extrêmement important et il est tout aussi primordial que les deux autres points. En fait il est primordial pour toute activité humaine si tu veux pas avoir déconvenue sur déconvenue. Le truc, c'est que rien n'est facile. C'est comme ça, on n'y peut rien. Si quelqu'un vous raconte que tout est trop simple pour lui et tout lui tombe tout cuit dans la bouche, c'est simple: il ment. Donc là où ça en vaut la peine? Ben perso, je considère que tout ce que je fais en vaut la peine (sinon je le ferais pas), et donc je persévère.

        Et surtout — je le disais — tout est lié. Si tu persévères, par exemple dans tes patchs, c'est aussi parce que tu es compréhensif et bienveillant. En effet si ton patch est oublié dans un coin, c'est pas parce que le mainteneur est méchant. C'est que comme toi, il a aussi une vie, et il est humain. Ainsi peut-être a-t-il oublié qu'il voulait regarder ton code plus en détail plus tard? Peut-être qu'il fait ça dans son temps libre avec peu de temps. Il vient peut-être d'avoir un nouveau né. Sa famille lui reproche peut-être de pas donner assez de temps. Tout simplement il reçoit 5 patchs par jour et il est seul à gérer le projet. Ou que sais-je encore?!

        Donc quand tu persévères et rappelle (pas trop mais une fois de temps en temps) que tu veux toujours voir ton patch inclus, tu es en fait d'une grande aide. Tu montres que tu t'y intéresses et ainsi aide le mainteneur à gérer ses priorités en choisissant quels patchs regarder en premier dans le peu de temps qu'il peut/veut y consacrer.
        Persévérer, c'est donc accepter le fait qu'autrui est aussi humain. C'est donc aussi comprendre l'autre et être bienveillant. Je le disais, tout est lié. Si un contributeur n'est pas prêt à comprendre cela, alors désolé mais son patch n'aura pas la priorité si on manque de temps. Il aura alors créé sa propre déconvenue.

        Tes exemples sont en fait peu représentatif du problème que tu cites, car ce sont des cas qui se sont passés sans accroc (4 commentaires dans le lien que tu donnes!) avec un petit code de juste quelques dizaines de lignes. La question, c'est: comment gèreras-tu un cas où ça se passe différemment? Si tu abandonnes parce que t'as pas de réponse immédiate, faut pas t'attendre à grand chose. Et pire si tu choisis tes projets en regardant d'abord si les mainteneurs ont plein de temps libres et répondent super vite, il te reste plus tant de projets intéressants auxquels contribuer (les projets les plus intéressants ont beaucoup de patchs, et par conséquent le temps de réponse/réaction des mainteneurs est beaucoup plus long en moyenne; ce sont mes stats persos au doigt mouillé ;P).

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

        • [^] # Re: J'ai lu, je ne suis pas d'accord

          Posté par  . Évalué à 3. Dernière modification le 09 novembre 2018 à 00:09.

          Il était très bien ton commentaire. Des penchants perfectionnistes? :P

          D'après moi le point de persévérance est extrêmement important et il est tout aussi primordial que les deux autres points. En fait il est primordial pour toute activité humaine si tu veux pas avoir déconvenue sur déconvenue. Le truc, c'est que rien n'est facile. C'est comme ça, on n'y peut rien. Si quelqu'un vous raconte que tout est trop simple pour lui et tout lui tombe tout cuit dans la bouche, c'est simple: il ment.

          C'est juste!

          Tu choisis tes projets en fonction de ton besoin, pas de la situation qui fait qu'un projet sera peut-être plus complexe/long à gérer. Ou alors je sais pas trop comment tu gères tes priorités, mais c'est étrange pour moi.

          Et bien je gère mes priorités avec une simple analyse coût/bénéfice (à la louche).

          Le bénéfice, c'est du temps. La fonctionnalité que j'ai rajouté au projet square/moshi était déjà possible, mais en ouvrant la boîte noire de comment le truc fonctionnait. C'était intéressent d'ouvrir la boîte noire, mais je me sens content à l'idée qu'il y a peut-être eu des centaines de devs qui ont pu rentrer chez eux 30 minutes plus tôt parce que j'ai mis une option commune à portée d'IDE.

          Le coût, c'est du temps aussi. Le temps que j'investis dans ma contribution. J'aime bien contribuer au libre, mais j'aime aussi me promener avec mon chien, jouer du piano, apprendre le japonais.

          En effet si ton patch est oublié dans un coin, c'est pas parce que le mainteneur est méchant. C'est que comme toi, il a aussi une vie, et il est humain. 

          Mais tout à fait! Et je ne leur jette pas la première pierre! Moi aussi j'ai été (genre ici) dans la peau du mainteneur qui lance un projet et l'abandonne aussitôt, ou n'est pas organisé pour accepter les contributions.

          Tes exemples sont en fait peu représentatif du problème que tu cites, car ce sont des cas qui se sont passés sans accroc (4 commentaires dans le lien que tu donnes!) avec un petit code de juste quelques dizaines de lignes. La question, c'est: comment gèreras-tu un cas où ça se passe différemment? Si tu abandonnes parce que t'as pas de réponse immédiate, faut pas t'attendre à grand chose. Et pire si tu choisis tes projets en regardant d'abord si les mainteneurs ont plein de temps libres et répondent super vite, il te reste plus tant de projets intéressants auxquels contribuer

          Ce n'est pas que j'abandonne, c'est que j'ai plusieurs projets en parallèle et qu'à un moment donné je m'investis là où ça a le plus de sens.

          C'est une approche réaliste, parce que honnêtement il vaut mieux contribuer à un projet square qu'à mon projet abandonné. Mais c'est aussi je pense une approche respectueuse car pour un mainteneur débordé, une courte contribution (MVP) c'est plus facile à gérer.

          Du coup mais exemples peu représentatifs parce qu'ils se sont passés sans accroc? Mais oui, c'est justement le point : c'est le type d'interaction idéale que j'aimerais se voir se reproduire.

          Et du coup j'en reviens à ta remarque "rien n'est simple" et à ta question: "que faire quand ça se passe autrement?". Et bien je réfléchis sur comment faire que la prochaine fois le problème ne se répète pas. Et c'est là dessus que je porte mes efforts. C'est beaucoup d'organisation, améliorer la documentation, mettre en place un guide de contribution, une CI, documenter les problèmes et les solutions…

          Comme disait Frédéric Chopin: "Dans un dernier effort, j'efface jusqu'à la trace de l'effort".

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.