Comment formulez-vous «c'est open source, soumettez un patch» pour qu'il soit convivial?

18

Dans les réponses de Quelle est la riposte canonique à "c'est open source, soumettre un patch"? , de nombreuses personnes ont exprimé l'opinion que le simple fait de demander aux gens de soumettre un patch est arrogant et grossier.

Mais il me semble qu'en tant que développeur sur n'importe quel projet open source, vous verrez beaucoup plus de demandes de fonctionnalités sur la liste de diffusion que vous pourriez éventuellement implémenter. Ainsi, lorsqu'un utilisateur dit: «J'aimerais voir la fonctionnalité X», la vérité est généralement que les chances de sa mise en œuvre sont assez minces à moins de soumettre lui-même un correctif. De plus, il suffit parfois d'un peu d'encouragement pour transformer un utilisateur en contributeur.

D'un autre côté, vous ne voulez pas effrayer les contributeurs (potentiels) en vous montrant impoli.

Alors, comment diriez-vous "veuillez soumettre des correctifs au lieu de demander des fonctionnalités" de manière conviviale?

Mise à jour: Merci pour toutes les suggestions! Je vois que la plupart d'entre eux nécessitent des explications assez longues. Mais comme je préfère éviter soit (a) d'expliquer la même chose tous les deux jours (cela prend juste trop de temps), soit (b) d'utiliser des extraits que je colle dans un e-mail (cela devient impersonnel très rapidement), je me demande: quelqu'un a-t-il écrit cela dans un document auquel je peux lier?

(Les choses spécifiques au projet, comme la façon d'écrire des tests, de compiler le code et de soumettre le correctif, doivent encore être documentées, bien sûr, mais je pense que ces problèmes techniques devraient de toute façon entrer dans CONTRIBUTING.txt.)

open-source Jo Liss
la source
10
Très important, si vous n'avez pas l'intention d'accepter les correctifs, ne le demandez pas! Autrement dit, si vous dites «Soumettre un correctif», vous devez être prêt à accepter un correctif propre et bien écrit.
edA-qa mort-ora-y
1
@ edA-qa - pas nécessairement tous les correctifs propres et bien écrits - mais si vous êtes susceptible d'opposer votre veto à de nouvelles fonctionnalités, vous devriez probablement avoir un moyen de vous proposer ces fonctionnalités pour une réponse probablement / probablement pas avant d'investir beaucoup de le temps de les développer.
Steve314
@Steve, je ne parle pas des correctifs non sollicités , ce sont des histoires différentes. Je veux dire spécifiquement comme dans la question, si vous dites à quelqu'un de soumettre un patch.
edA-qa mort-ora-y
Ce n'est arrogant et grossier que lorsque vous voulez vraiment dire "cela peut ou non être une bonne idée, partez". Si vous pensez honnêtement que c'est une mauvaise idée, dites-le. Si vous voulez dire que c'est vraiment une bonne idée que vous n'avez pas le temps de mettre en œuvre, dites-le. Et indiquez que vous seriez prêt à accepter un correctif qui implémenterait cette fonctionnalité. (De cette façon, peut-être que quelqu'un soumettra un correctif.) Le problème avec le simple fait de «soumettre un correctif» est vague et dédaigneux.
David Schwartz

Réponses:

8

Non.

Dans la mesure où je l'ai vécu, les contributeurs candidats sont des bricoleurs et ne soumettront pas de demande de fonctionnalité en la demandant simplement. Ils le demandent généralement avec un certain niveau de participation déjà:

  • Ne serait-ce pas doux si [...]? Il pourrait être possible de faire A, B et C. (C'est un appât pour: je n'ai pas le temps mais voici une idée précise au cas où vous le feriez.)
  • Voici un correctif à faire / voici un correctif pour [...].
  • J'envisage d'écrire un patch à [...] faire et je pourrais utiliser la rétroaction / est-ce que quelqu'un est intéressé à aider.
  • Etc.

Les codeurs qui soumettent une demande de fonctionnalité pure et simple le font généralement pour une raison. Certains d'entre eux incluent (et je sais pertinemment que les deux derniers se produisent dans WordPress, par exemple):

  • Ils sont profondément ancrés dans d'autres projets open source, c'est-à-dire qu'ils n'ont pas le temps.
  • Ils sont des free-riders et ont l'intention de garder les choses de cette façon.
  • C'est bien au-delà de leur niveau de compétence / écrit dans une langue qu'ils ne connaissent pas.
  • Ils utilisent le logiciel par manque d'une meilleure option et ne veulent pas avoir affaire à une pile malodorante de code batsh * t ^ \ b.
  • Ils ne peuvent plus être dérangés car leurs correctifs antérieurs ont été ignorés / rejetés, c'est-à-dire qu'ils pensent qu'ils perdraient leur temps.

Plus généralement, les demandes de fonctionnalités proviendront d'utilisateurs finaux qui ne pourraient pas contribuer au correctif même s'ils le voulaient. Surtout lorsqu'ils sont soumis en dehors du système de billetterie.

Je pense que votre priorité la plus importante devrait être de ne pas repousser les contributeurs potentiels / existants, plutôt que d'essayer d'en recruter activement de nouveaux. C'est extrêmement important, et je le dis par expérience. J'ai une façon étrange de choisir une nouvelle base de code, ce qui implique une lecture rapide du code pour en avoir un certain niveau, sauter dans le système de billetterie et corriger des bogues faciles à regarder pour apprendre les internes en profondeur (et classer nouveaux que je teste). Au fil des ans, j'ai inondé quelques projets de dizaines de tickets et de patchs. Souvent, ces tickets ne recevront que peu ou pas d'attention en temps opportun (pas même une reconnaissance, par exemple, continuez!) - y compris lorsqu'ils sont accompagnés d'étapes de diagnostic documentées et de tests unitaires.

Denis de Bernardy
la source
1
Je ne pourrais pas être plus d'accord. Il semble y avoir un sentiment général parmi les projets F / OSS que quiconque soumet une demande de fonctionnalité est juste paresseux et pourrait soumettre un correctif / modifier sa propre installation s'il voulait vraiment cette fonctionnalité. C'est extrêmement rebutant pour quiconque ne sait tout simplement pas comment programmer ou n'a pas le temps parce qu'il est impliqué dans d'autres projets. Ce ne sont pas les mots «soumettre un patch» qui sont grossiers, mais l'hypothèse que l'utilisateur n'a rien d'autre dans son assiette.
Shauna
9

En bref, vous expliquez que vous n'avez pas un temps illimité pour faire leur travail gratuitement. (Vous pouvez sauter le bit 'gratuitement'), et qu'ils peuvent contribuer à tout moment, ce n'est pas "votre" projet, c'est le projet de tout le monde.

donc vous dites "Nous sommes vraiment désolés, c'est une excellente idée, mais nous sommes tout simplement trop occupés avec tous les autres travaux en cours, nous l'ajouterons à la liste, mais si vous souhaitez vraiment intégrer cela, et vous aimeriez nous aider en contribuant au projet, ce serait merveilleux. Nous avons de la documentation pour aider les gars à apporter des modifications au projet, ils sont là, donc si vous avez les compétences et le temps et que vous souhaitez nous aider, alors n'hésitez pas à nous envoyer un patch avec vos modifications. Nous devrons peut-être y apporter des modifications lorsque nous l'obtiendrons afin qu'il corresponde aux normes du projet, mais vous nous une grande faveur en nous donnant au moins un coup de pouce pour ce travail et nous vous aimons pour nous aider ".

Bien sûr, une fois que vous commencez à demander des correctifs, vous ne pouvez jamais, jamais les laisser allongés sur votre système de ticket trop longtemps, si vous en avez beaucoup, vous les intégrerez plus que le travail que vous faisiez auparavant. Vous n'aimerez peut-être pas cela, mais c'est nécessaire si vous voulez que les correctifs continuent de venir.

gbjbaanb
la source
J'aime ça. C'est peut-être en fait quelque chose de mieux à mettre dans la documentation afin que vous n'ayez pas à le copier-coller chaque fois que vous avez besoin d'expliquer cela. Et puis vous dites simplement "Souhaitez-vous contribuer un patch? Http: //.../#contributing"
Jo Liss
@JoLiss: Vous avez critiqué ma réponse pour avoir semblé impersonnel; comment pensez-vous qu'il est préférable de copier-coller un lien hypertexte vers une FAQ? Si vous allez utiliser une réponse standardisée, utilisez-en une qui montre soit de l'empathie, soit un son professionnel (ou les deux). Cette idée de raccourci n'est ni l'un ni l'autre; en fait, c'est précisément le genre de grossièreté dont se plaignait la question initiale.
Aaronaught
Huh, intéressant. Je ne savais pas que les gens trouveraient nécessairement cela impoli si vous publiez un lien. D'un autre côté, je trouve que les réponses en conserve se révèlent très impersonnelles. Alors peut-être est-il préférable de simplement taper ce genre d'explication quand elles arrivent.
Jo Liss
6

Restez poli et expliquez clairement la situation. Et quelque chose comme:

Merci pour votre avis. Nous trouvons votre fonctionnalité très intéressante, mais malgré nos efforts pour implémenter la plupart des fonctionnalités demandées dans notre produit, nous n'avons pas assez de temps pour les implémenter toutes. Si vous êtes développeur, vous pouvez nous rejoindre en contribuant au projet, car il est open source.

Vous voyez, vous ne pouvez pas simplement dire "Pourquoi me dérangez-vous avec vos demandes? Je ne suis pas ici pour travailler gratuitement pour vous; si vous voulez cette fonctionnalité, allez l'implémenter vous-même". La personne peut être un non-développeur, peut ne pas connaître la langue utilisée pour développer le produit, etc.

Ainsi, au lieu d'être impoli, vous pouvez suggérer de participer au projet et expliquer également pourquoi vous ne pouvez pas implémenter la fonctionnalité vous-même.

Une autre façon de ne pas être impoli est de ne rien dire. Si vous avez un site Web où les utilisateurs de votre application peuvent suggérer de nouvelles fonctionnalités et signaler des bogues, vous pouvez vouloir trier les éléments par leur priorité: par exemple, si une fonctionnalité est demandée par 10 000 utilisateurs et une autre par 10 seulement , il est possible que le premier soit implémenté en premier.

Sur un tel site Web, vous pouvez toujours mettre une suggestion "implémentez-le vous-même" pour les fonctionnalités qui, après quelques jours ou semaines, n'ont pas reçu suffisamment de votes positifs d'autres utilisateurs.

Arseni Mourzenko
la source
5

Merci pour votre requête. Nous l'avons ajouté à notre carnet de projets et nous l'examinerons sous peu.

Veuillez noter qu'en raison du volume de demandes, nous ne pouvons garantir que chacune sera mise en œuvre. Nous comptons sur des bénévoles, donc si vous êtes développeur, pensez à donner un peu de votre temps et à soumettre un patch . Sinon, sachez que nous travaillons tous dur pour surmonter l'arriéré et que nous répondrons à votre demande dès que possible.

Vraiment, était-ce si difficile?

Aaronaught
la source
+1 excellent; belle réponse professionnelle. @Jo Liss: gardez à l'esprit que la plupart des gens veulent simplement utiliser le logiciel, pas y consacrer leur vie.
Steven A. Lowe
J'aime son essence, mais je pense personnellement que le ton est un peu trop impersonnel. Vous n'êtes généralement pas une entreprise de service client, vous êtes juste un développeur qui parle à un pair. Même les gens à 37 signaux évitent ce type de langage .
Jo Liss
@JoLiss Vous êtes en train de faire le service à la clientèle, si vous voulez le croire ou non. Et vous n'avez rien dit sur les "pairs". Il est possible que la personne à qui vous parlez soit un développeur, mais à moins que vous ne le sachiez pour un fait, je ne pense pas que ce soit une hypothèse appropriée à faire (sauf si vous travaillez sur des outils de développement, mais vous n'avez pas précisé que dans la question). Enfin, les gars à 37 signaux parlant de ce qui constitue des conneries est ... ironique, c'est le moins qu'on puisse dire.
Aaronaught
Hm. Je ne suis pas sûr de vouloir donner l'impression que je fais du service à la clientèle ... Votre argument selon lequel les utilisateurs ne sont pas nécessairement des pairs est bien entendu. Concernant 37signals, voici un autre article de blog qui parle de ton - je pense que le point n'est pas tant que vous ne devriez pas faire de conneries, mais que vous ne devriez pas vous en sortir comme une société sans visage. À mon avis, c'est une bonne stratégie, et c'est encore plus vrai pour les projets open source.
Jo Liss
2
@JoLiss: Si vous voulez être plus personnel que ça, génial, tout le pouvoir pour vous - c'est, pour moi, la norme minimale que vous devez respecter en termes de courtoisie. Ne vous contentez pas de dire «soumettre un patch» - expliquez que vous êtes occupé, pas paresseux ou désintéressé; reconnaissez qu'ils pourraient ne pas être en mesure de soumettre un patch, et que même s'ils le sont, ils vous rendraient toujours service en vous obligeant.
Aaronaught
4

Eh bien, au lieu de simplement dire «soumettre un patch», vous devriez élaborer un peu plus.

  • Précisez clairement que vous n'avez pas le temps de le faire maintenant ou dans un avenir prévisible, donc si d'autres veulent qu'il soit implémenté rapidement, il n'y a pas d'autre moyen que de fournir un patch.
  • Prenez le temps d'évaluer la fonctionnalité. Si vous l'aimez sincèrement, il n'y a aucun mal à le dire. Encourager les gens. Ou si vous pensez que la fonctionnalité est vraiment mauvaise, prenez le temps de l'expliquer.
  • Fournissez une aide au démarrage. Personne ne connaît la base de code comme vous. Vous n'avez pas le temps de le faire, mais vous savez probablement exactement comment vous le feriez et par où commencer. En 5 à 10 minutes, vous pouvez partager les connaissances que d'autres auraient besoin d'heures pour comprendre. Cela permet également à votre image globale de prévaloir. Au lieu d'avoir des fonctionnalités étrangères intégrées à votre projet, vous pouvez guider les contributeurs vers une belle intégration.
back2dos
la source
Je suis d'accord avec cela, mais j'ajouterais que vous avez besoin de directives très claires sur ce que vous attendez d'un patch. (par exemple conforme aux normes du code, testé à l'unité, documenté). Ceci est important, car il est très probable que ce soit vous qui devrez prendre en charge la fonctionnalité - les auteurs de correctifs restent très rarement sur place pour corriger leurs bogues ou offrir une assistance aux autres utilisateurs de votre bibliothèque.
Mark Heath
3

Voici ce que je dis généralement ...

"C'est une suggestion intéressante et ce serait cool si FooBarLib pouvait le faire. Malheureusement, FooBarLib est juste un projet de temps libre pour moi, donc il est peu probable que j'y parvienne dans un avenir proche. Je salue les soumissions à FooBarLib, donc si vous êtes en mesure de l'implémenter vous-même, n'hésitez pas à soumettre un patch (assurez-vous de lire nos directives "comment contribuer à FooBarLib" en premier). "

Mark Heath
la source
2

En plus des belles façons de dire «Soumettre un correctif», fournissez également une documentation destinée aux développeurs afin que les autres personnes qui souhaitent vraiment que la fonctionnalité puisse se mettre à jour facilement sur votre projet. De nombreux projets ne sont pas conviviaux pour les développeurs et nécessitent des jours au minimum de lecture de milliers de lignes de code et de tonnes de petits cas de test poussant sur différentes parties du système pour bien fonctionner.

Si vous fournissez de l'aide aux développeurs possibles, ils seront plus que disposés à fournir de l'aide. Cela signifie une bonne documentation de code, de bonnes pages wiki expliquant le flux (ou un bon diagramme UML / tableau blanc) et un moyen facile d'obtenir les correctifs acceptés.

TheLQ
la source
-2

J'adore la façon dont github encourage les autres à bifurquer le projet. Plusieurs versions du même projet peuvent exister sous différents comptes d'utilisateurs. Si vous n'aimez pas la direction que je prends le projet, merci de le bifurquer. Vous pouvez facilement soumettre des demandes de tirage mais n'êtes pas bloqué en attendant que je l'accepte.

Donc ma réponse est souvent, il suffit de la fourche.

mcotton
la source