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 ]
# J'ai lu, je ne suis pas d'accord
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal The Minimum Viable Pull-request. É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
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:
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).
Ç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).
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:
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 ]