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

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.)

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.

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.

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.

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?

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.

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). "

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.

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.