Qu'est-ce que la réplique canonique à "c'est open source, soumettre un patch"? [fermé]

215

Le danger de jamais suggérer une fonctionnalité sur un produit, notamment open source, est que vous obtiendrez la réponse "pourquoi ne pas le faire?".

C'est valide, et c'est cool que vous puissiez faire le changement vous-même. Mais nous savons pratiquement que les produits s’améliorent souvent lorsque les programmeurs écoutent la voix des utilisateurs - même si ces utilisateurs sont d’autres programmeurs. Et, pour apporter ces changements de manière efficace, il peut être utile de faire appel à une personne qui travaille déjà sur le projet et qui la concrétise.

Certains termes courants sont utilisés pour désigner des problèmes de développement de logiciels. par exemple Bikeshedding . Existe-t-il un terme commun qui réponde en substance: "Oui, je sais que je peux changer à peu près tout dans le monde - même dans le cas d’une source fermée. Je pourrais être embauché et écrire ce code. Mais dans ce cas, je ne fais que une observation qui peut en fait être utile pour un autre codeur déjà bien placé pour effectuer facilement ce changement - ou simplement pour discuter des possibilités en général. "

[ps (quelques jours) - J'aurais dû préciser que "soumettre un patch" est souvent dit avec un humour ironique et je cherche une réponse spirituelle appropriée.]

Vincent Scheib
la source
16
Je souhaite que je pourrais upvoter plus d'une fois! (Et cela vient de quelqu'un qui a soumis des correctifs à une poignée de projets différents et les a acceptés. Cette attitude que vous décrivez est tout simplement agaçante!)
Mason Wheeler
62
Je suppose "à quoi je ressemble, un singe au code au chômage? J'ai une vie!" n'est pas une réplique acceptable ;-)
Steven A. Lowe
12
D'après mon expérience, la réponse "soumettre un correctif" survient généralement après que le développeur a déjà expliqué pourquoi l'ajout de la fonctionnalité ne serait pas pratique.
user16764
7
@Steven, dépend de votre désir de vaincre l'insulte ou de lui faire faire ce dont vous avez besoin. Je crois que ce n'est pas une stratégie optimale si vous voulez le dernier.
12
@orokusaki: Ou D) Ils considèrent que la fonctionnalité est moins utile que d'autres fonctionnalités sur lesquelles ils pourraient travailler, et ils disposent de ressources limitées.
David Thornley

Réponses:

115

C'est un point difficile: étant donné que l'utilisateur ne paie pas directement ou indirectement un produit, il ne peut pas demander la mise en œuvre d'une fonctionnalité. Ce n'est pas comme si vous étiez un intervenant ou un client direct qui avait commandé le produit, et même pas l'utilisateur final d'un produit commercial.

Ceci étant dit, "soumettre un patch" n'est pas une réponse valide. Ce n'est pas poli. Ce n'est pas correct. Même pour un produit open source. "Submit a patch" est la version courte de:

"Peu importe que vous aimiez notre produit ou non. Modifiez-le si vous le souhaitez, mais ne nous embêtez pas avec les demandes de vos clients."

Qu'en est-il de soumettre un patch?

Eh bien, ce n'est pas si facile. Pour le faire:

  • Vous devez connaître la ou les langues utilisées dans le projet open source.

  • Vous devez pouvoir charger le code source à partir du contrôle de version pour pouvoir le modifier.

  • Vous devez avoir toutes les versions correctes de toutes les dépendances de construction installées (y compris les bibliothèques d'exécution et les outils de construction).

  • Vous devez être capable de compiler ce code source , ce qui n’est pas si évident dans certains cas. En particulier, lorsqu'un projet énorme prend quelques heures à compiler et affiche 482 erreurs et des milliers d'avertissements, vous pouvez avoir le courage d'aller à la recherche de la source de ces erreurs.

  • Vous devez très bien comprendre comment le projet est réalisé , quel style de codage utiliser, le cas échéant, comment exécuter des tests unitaires, etc. Si le projet ne dispose pas d'une documentation correcte (ce qui est souvent le cas pour les projets open source ), cela peut être vraiment difficile.

  • Vous devez vous adapter au projet et aux habitudes des développeurs qui participent activement au projet. Par exemple, si vous utilisez .NET Framework 4 quotidiennement, mais que le projet utilise .NET Framework 2.0, vous ne pouvez utiliser ni LINQ, ni les contrats de code, ni d'autres milliers de nouvelles fonctionnalités des dernières versions du framework.

  • Votre patch doit être accepté (à moins que vous ne fassiez le changement que pour vous-même, sans intention de le partager avec la communauté).

Si votre intention est de participer activement au projet, vous pouvez faire toutes ces choses et y consacrer votre temps. Si, au contraire, il ne reste qu'un bogue mineur ou une simple fonctionnalité manquante, passer des jours, des semaines ou des mois à étudier le projet, faire le travail en quelques minutes est déraisonnable, à moins que vous ne l'aimiez.

Alors, y a-t-il une réplique canonique à "c'est open source, soumettre un correctif"? Je ne pense pas. Soit vous expliquez à la personne qu'elle est impolie, ou vous arrêtez simplement de lui parler.

MainMa
la source
9
Cela semble avoir été écrit par une personne sans expérience dans la maintenance d'un projet open source.
Rein Henrichs le
46
@Rein: La maintenance d'un projet open source n'est pas différente de la maintenance d'un autre projet. Vous avez des clients. Si vous ignorez ces clients, ils cesseront de vous donner de précieux commentaires et iront ailleurs pour trouver leurs solutions. Cela convient peut-être aux personnes open source, mais j'aimerais bien savoir si j'allais être totalement responsable de la correction des bogues d'un logiciel open source, car cela me ferait réfléchir à deux fois avant de l'utiliser.
Robert Harvey
17
@ Rein: Eh bien, jusqu'à présent, je vous ai entendu dire deux fois que nous ne savons pas de quoi nous parlons. Peut-être que vous pouvez nous éclairer, hein?
Robert Harvey
8
@ Rein Henrichs: Vos deux premiers commentaires sont des attaques "ad hominem". S'il y a des différences entre les deux, dites ce qu'ils sont plutôt que de dire que les autres ne savent rien.
Andrew Grimm le
13
Je soupçonne que l’intention était: "La maintenance d’un projet open source n’est pas différente de la maintenance de tout autre projet en ce qui concerne l’écoute des commentaires des clients et le maintien de leur bonne volonté." Si tel est le cas, je suis tout à fait disposé à y renoncer, mais, en tant que personne ayant géré plusieurs projets FOSS avec une poignée, voire des centaines de contributeurs, je trouve la déclaration générale originale "incorrecte".
Rein Henrichs le
79

La réplique canonique est de soumettre un correctif.

wnoise
la source
47
Ou mieux encore, de dire: "Je l'ai déjà fait il y a six mois. Quand allez-vous commencer à l'examiner et à le commettre?"
Bob Murphy
14
Normalement, je n’aime pas les réponses courtes, mais c’est vraiment le seul moyen de répondre qui garantit d’aboutir au résultat recherché. Ils ont clairement indiqué le meilleur moyen possible d'atteindre votre objectif. Pourquoi se contenter d'une solution moindre?
19
-1 réponse de connard open source. Pas utile. (Désolé.) Il n'y a pas de "réplique" canonique. La meilleure réponse (en supposant que le PO ne peut pas simplement soumettre un correctif, ce qui est selon moi une hypothèse raisonnable dans ce cas-ci) est l’un des (1) "Je n’ai ni les capacités ni les ressources pour générer un correctif [et éventuellement inclure lien vers cette question même] ", (2) eyeroll, pas de réponse, utilisation d'un outil dans son état actuel, ou (3) recherche d'un meilleur outil.
JohnL4
1
Ce n'est pas nécessairement un patch. Fournir des commentaires détaillés et raffinés est également utile. Tout ce que cela veut dire, c'est que vous ne devez pas attendre de moi que j'investisse mon temps pour répondre à vos besoins spécifiques si vous n'avez rien à offrir en retour.
Evan Plaice
67

C'est la réponse habituelle lorsque les développeurs ne pensent pas qu'ils vont arriver à faire quelque chose dans un délai raisonnable, mais cela a été évoqué à plusieurs reprises.

C'est très injuste quand on en a parlé à plusieurs reprises, mais la personne qui a récemment mentionné le fait ne le sait pas et dit simplement "nous prenons des correctifs pour cela" tout de suite. Dans ce cas, le responsable en a marre de la discussion, mais l'utilisateur pense que c'est un nouveau sujet. Quoi qu'il en soit, il est fort probable que si vous «prenez les correctifs» tout de suite, vous ne devriez pas le prendre personnellement, mais vous voudrez peut-être lire les archives et le suivi des bogues pour plus de détails sur le problème.

Si vous formulez vous-même une demande à plusieurs reprises, "prendre des correctifs" est potentiellement censé être un pinceau relativement poli, par opposition à des alternatives moins polies ...

Et bien sûr, il y a des mainteneurs impolis qui diront "prendre des correctifs" sans explication à qui que ce soit, mais je dirais que c'est une minorité.

Si vous avez déjà géré un projet open source avec de nombreux utilisateurs, vous saurez qu'il y a 100 fois plus de demandes que les responsables de la maintenance ne pourraient jamais en obtenir, et que beaucoup de ces demandes sont importantes pour le demandeur, mais seraient incroyablement difficiles. ou perturberait de nombreux autres utilisateurs, ou présenterait une autre faille visible uniquement avec une compréhension globale du projet et de la base de code. Ou parfois, il y a juste des jugements, et il faut trop de temps pour se disputer encore et encore.

La plupart des entreprises non-open-source ne vous donneront absolument pas accès aux développeurs et vous obtiendrez simplement le traitement silencieux ou une histoire polie mais fictive du support client. Donc, en open source au moins, vous avez quelques options (payer quelqu'un pour coder la fonctionnalité, etc.) et, bien que les développeurs puissent être impolis, au moins ils donnent des réponses franches. Je préférerais "non" à l'habituel "c'est sur notre feuille de route ... [2 ans plus tard] ... c'est toujours sur notre feuille de route" du genre de chose que j'ai eu chez un certain nombre de fournisseurs ...

Donc, je ne pense pas qu'il y ait une réplique. Peut-être que le mainteneur open source est vraiment très occupé, peut-être est-ce un imbécile, mais de toute façon, ils ont probablement un travail difficile et se lancer dans un débat qui a le dernier mot ne mène à rien. Le mieux que vous puissiez faire est de contribuer d'une manière ou d'une autre et d'essayer d'être constructif.

Peut-être que ce n'est pas du code, mais il y a peut-être beaucoup d'analyses et de documentation de scénarios utilisateur que vous pourriez faire. Lorsque je maintenais le gestionnaire de fenêtres GNOME, il aurait souvent été utile d’analyser un problème de manière globale en tenant compte de tous les utilisateurs et d’écrire les problèmes, les avantages et les inconvénients et ce qui devrait se passer dans une perspective globale.

(Au lieu de cela, la chose habituelle était de commencer à flamber comme s’ils étaient le seul utilisateur qui importait et qu’il n’y avait pas de compromis. Et bien, c’est génial et c'était un point de données, et souvent je réussissais à rester poli ou même à résoudre leur problème par la suite. flaming ne fait rien arriver plus vite, il confond simplement les émotions et fait perdre le temps à tout le monde.)

Havoc P
la source
4
@Aaronaught J'ai parcouru des centaines de projets open source et je n'ai pas remarqué le bricolage comme réponse par défaut. C'est une réponse à certaines demandes.
Havoc P
2
Tout ce que je dis, c’est, je pense plus souvent qu’autrement, il ya une raison pour laquelle le responsable de la maintenance est au moins un peu malade d’un sujet (ou d’une personne) avant de dire «prenant des patchs» et il peut être intéressant de chercher pourquoi. obtenu cette réponse. C'est mon expérience, fwiw. Si la question ici concerne des cas où il n'y a aucune raison d'être malade du sujet ou de la personne, alors bien sûr, "prendre des correctifs" n'est probablement pas une bonne chose à dire au responsable. Les gens font des fautes. Je dis toujours que je doute qu'une réplique (ou une méta-discussion comme celle-ci) puisse aider, mais engager de manière constructive peut parfois l'être.
Havoc P
5
De plus, alors qu'il peut être formulée plus ou moins poliment, si un mainteneur a un arriéré de travail dans leur esprit, ils ont probablement une chose qu'ils peuvent se rendre à eux - mêmes, pour 100 choses qu'ils pourraient prendre un patch pour parce qu'ils voudraient le fonctionnalité; et puis il y a encore une autre catégorie de changements qu'ils rejetteraient même si quelqu'un d'autre faisait le travail. Il doit donc y avoir un moyen de communiquer "Je prendrais ce changement, mais je n’ai pas prévu de le faire moi-même." Certaines personnes ici semblent penser que "Bien sûr, venir tout de suite" est la seule réponse acceptable. Mais "prendre des correctifs à ce sujet" est une vraie catégorie.
Havoc P
2
@Aaronaught, cela ressemble à de bons phrasés. Je pense que souvent, "nous ne prendrions pas un patch pour ça", mais les programmeurs ne sont généralement pas les types les plus sensibles sur le plan émotionnel, ils peuvent se précipiter dans les e-mails et le ton ne retransmet pas très bien le texte, il est donc facile de tomber sur le sujet.
Havoc P
2
En fait, "nous prendrions un correctif pour cela" est différent de deux manières subtiles mais importantes: (1) il ne responsabilise pas directement l' utilisateur , et (2) il reconnaît que la demande a été sérieusement prise en compte bien qu'elle ne soit pas prise en compte. mis en œuvre. Bien que le résultat net soit essentiellement identique, la réponse est beaucoup plus humaine. (Néanmoins, il ne serait pas mal d'ajouter explicitement ce qui est impliqué ... mais nous n'avons pas les ressources pour le résoudre nous-mêmes pour l'instant. )
Aaronaught
43

La raison pour laquelle vous obtenez cette réponse n’est pas que les responsables sont des imbéciles, mais bien que vous ne les avez pas suffisamment convaincus de la proposition de valeur qu’ils travaillent sur votre fonctionnalité pour vous .

La meilleure solution consiste à entamer un dialogue sur la valeur de votre fonction pour la communauté dans son ensemble , afin de voir si vous pouvez le convaincre de changer d'avis. Peut-être ont-ils raison et savent-ils plus que vous sur les besoins de leur propre communauté - mais, encore une fois, peut-être que non.

Si cette fonctionnalité n’est utile que pour vous et n’a que peu ou pas de valeur pour la communauté, j’aperçois que l’argent est un excellent facteur de motivation, alors que se plaindre de leur attitude ne l’est pas.

Rein Henrichs
la source
15
Bien sûr, ce sont peut-être des secousses. Cette réponse seule n'est pas un indicateur très précis, car elle est également utilisée par les non-saccadés lorsque le demandeur est un imbécile.
Rein Henrichs
4
J'aimerais également ajouter qu'en l'absence d'argent, vous pouvez souvent échanger des contributions en nature contre une tâche quelconque: aidez à trier une file d'attente de problèmes achalandés, passez du temps dans le canal IRC et apportez de l'aide, testez des correctifs ou écrivez de la documentation. Les projets open source ont des ressources limitées et doivent en tirer le meilleur parti. Ajouter une fonctionnalité est viable si elle est importante pour suffisamment de personnes, ou importante pour ceux qui en donnent / donnent suffisamment. Si votre cas n'est pas le premier, faites-en le dernier.
HedgeMage
2
Honnêtement, le meilleur moyen de convaincre un développeur est de lui montrer à quel point sa base d'utilisateurs souhaite cette fonctionnalité. Les bugtrackers avec vote, les discussions sur les forums, etc. sont très utiles pour cela et sont utilisés dans de nombreux projets open source.
ProdigySim
4
De même, quand les gens obtiennent un RTFM ou DAFS comme une réponse, ou -1 sur SE, il est parce que l'interlocuteur n'a pas convaincu suffisamment de la answerer la proposition de valeur de répondre à leur question pour eux . Je suis sûr que beaucoup d’entre vous peuvent comprendre ce sentiment.
Rein Henrichs le
1
@Walter Yep, c'est pourquoi j'ai suggéré de convaincre la personne "de la valeur de votre film pour la communauté dans son ensemble".
Rein Henrichs le
31

Qu'est-ce que la réplique canonique à "c'est open source, soumettre un patch"?

Il n'y a pas de réponse raisonnable susceptible de faire une différence. Essayer de persuader les volontaires de faire quelque chose qu'ils n'ont aucune intention de faire est une perte de temps ... ou pire.

Vos options sont:

  • Faites ce que la réponse suggère. c'est-à-dire implémenter la fonctionnalité et la soumettre comme un correctif. Cela s'appelle "rendre quelque chose en retour".

  • Trouvez quelqu'un qui serait prêt à mettre en œuvre la fonctionnalité pour vous avec de l'argent réel. Il peut s'agir du projet lui-même (par exemple en échange d'un parrainage), d'une personne associée au projet ou d'un "codeur à embaucher" aléatoire.

  • Trouvez un produit alternatif.


Si vous avez reçu cette réponse lorsque vous avez fait une suggestion "utile", réfléchissez à la manière dont vous auriez pu réagir si vous étiez à sa place. Par exemple, comment répondriez-VOUS si vous pensiez que la suggestion n’était pas valable / bien réfléchie / intelligible / etc., mais n’aviez pas le temps ni la patience d’engager un débat prolongé?


J'ai été impliqué dans un projet d'exploitation open source de longue date, et l'un des problèmes les plus gênants concerne les personnes qui siègent dans la "galerie des arachides" et vous émeuvent de suggestions pour faire "mieux" les choses suivantes:

  • sont incomplets, inintelligibles ou complètement insensés,
  • sont des idées non essayées avec une chance de succès objectivement faible,
  • nécessiterait des efforts considérables pour mettre en œuvre et / ou
  • sont contraires aux objectifs déclarés du projet.

Souvent, la meilleure solution consiste à demander à la personne de s’impliquer de manière significative dans le projet… et d’espérer qu’elle profite de l’allusion… pour «se lever ou se taire». Malheureusement, les plus ennuyeux ne comprennent même pas.

Bien entendu, l'autre réponse à ces personnes est de ne pas répondre du tout ou de les ignorer complètement.

Stephen C
la source
7
"Comment réagiriez-vous si vous pensiez que la suggestion ne valait pas la peine / était bien pensée / intelligible / etc." - exactement comment tous les autres professionnels réagissent. "Pourriez-vous expliquer / donner quelques exemples de ce que vous demandez?" ou "Pourriez-vous me donner quelques informations sur les raisons pour lesquelles vous pensez avoir besoin de cette fonctionnalité?" ou "Et si nous faisions cette autre chose à la place, cela fonctionnerait-il pour vous?" ou que diriez-vous simplement "Merci pour votre suggestion, nous l'examinerons pour une version future." Ce sont des compétences interpersonnelles de base, pas de génie.
Aaronaught
12
@Aaronaught - Désolé, mais vous ne l'obtenez pas. Le développeur open source typique n'a pas le temps de s'engager dans des discussions polies mais finalement inutiles dans le but de caresser l'ego de ses "clients"; c'est-à-dire en faisant semblant de s'en soucier, lorsqu'une personne à demi intelligente se rend compte que c'est une façade. Et pour être franc, je trouve ce genre d'ego caressant la politesse d'être condescendant ... et PLUS offensant que de se faire carrément dire qu'il n'y a aucune chance qu'ils mettent en œuvre XYZ.
Stephen C
6
@kurige - en fait, si les personnes en question présentaient des correctifs, elles seraient définitivement prises en compte. Le problème est que les personnes en question sont "tout à fait en bouche"; c'est-à-dire aucun intérêt à faire aucun effort.
Stephen C
10
Parce que le développeur open source typique a déjà un travail et qu'il fait son développement open source pour le plaisir. Faire ce que les autres veulent que vous fassiez, c'est travailler. Faire ce que tu veux faire est amusant.
ProdigySim
8
@Aaronaught: Est-il nécessaire de traiter beaucoup de secousses avec respect? Dans un service public, il y aura des gens qui présenteront des demandes déraisonnables, souvent sous une forme insultante. Traiter avec des imbéciles impolis peut être une vraie douleur. Une exigence de respect envers eux conduirait un grand nombre de personnes à se soustraire à l'activité de F / OS, ce qui serait une perte pour tout le monde.
David Thornley
20

La réponse serait raisonnable si vous et le programmeur en question restiez égaux et saviez à peu près la même chose à propos de la base de code et du langage, ainsi que de tout ce qui concerne la chose que vous signalez.

Vous n'êtes pas égaux (ou vous l'auriez probablement fait), alors je suggérerais une réplique appropriée:

"Il est impossible que je puisse le faire aussi vite et bien que vous le pouvez, c'est pourquoi je vous ai demandé de m'aider en premier lieu. S'il vous plaît!"

Je pense qu’il est contraire à la nature humaine fondamentale de dire "Oh, oui, cette chose sur laquelle j’ai passé beaucoup de temps et est vraiment bonne, est si simple que quiconque peut venir de la rue et faire un aussi bon travail que moi. Je peux ".

utilisateur1249
la source
Sauf que ce n'est pas vraiment ce qu'ils disent du tout. Ils disent "ce que vous voulez n'est pas quelque chose que la communauté veut, alors nous ne sommes pas intéressés à travailler dessus. Nous pourrions accepter un patch si vous vouliez travailler dessus". Il est implicite "nous pourrions aussi changer d'avis si la communauté le veut". Rappelez - vous que « Je veux que vous aider à me » va à l' encontre de la nature fondamentale des projets open source , où (pour apporter toute la force de mon nerdery Star Trek à porter) le bien du nombre toujours l' emporte sur le bien de quelques - uns.
Rein Henrichs le
Eh bien, à moins que ces quelques-uns aient beaucoup d'argent, historiquement parlant.
Rein Henrichs le
2
@ Rein, non, ce qu'ils disent, c'est qu'ils ne veulent pas le faire. Tout ce que "la communauté veut" n'est qu'un homme de paille. Le problème est que celui de la COMMUNAUTÉ le demande.
1
"Il est extrêmement impoli de suggérer d'écrire un correctif si vous ne savez pas à l'avance que vous envisageriez de le prendre pour votre produit." D'accord. Comme je l'ai dit, c'est pourquoi je n'utilise pas cette réponse. Je peux sympathiser avec cela, cependant. "Si vous voulez sincèrement dire que" soumettre un correctif "a pour but de faire taire les gens au lieu de déléguer le travail, vous reconnaissez que cela a été demandé par un membre de la communauté et non par un développeur." Je ne suis pas vraiment sûr de ce que vous dites ici, désolé.
Rein Henrichs le
1
@ Thorbjørn Ah oui. En fait, les responsables de la maintenance open source que je connais ne pensent certainement pas de la sorte. En fait, nous nous efforçons de fournir des directives aux développeurs et de la documentation pour aider les gens à apprendre le projet et les conventions pour y contribuer, précisément parce que nous sommes conscients du déficit de compétences. Par exemple, rubini.us/doc/fr/contributing
Rein Henrichs le
16

La réplique canonique consiste à bifurquer le projet.

utilisateur16764
la source
8
ou soumettez un patch
Kamil Szot le
2
Que va t'apporter la bonne
1
@Thorbjorn: Tout le monde pourrait utiliser une bonne fourchette de temps en temps. Même une fourchette de pitié.
user18014
15

La réponse canonique à "soumettre un patch" est:

"Je n'ai ni les compétences, ni l'expérience ni le temps nécessaires, alors pouvez-vous s'il vous plaît me dire où envoyer les caisses de bière au gars qui peut le faire pour moi"

gbjbaanb
la source
13

Soumettez un cas de test complet .

alecco
la source
1
J'aime celui-ci, cependant, cela prend souvent plus de temps que de soumettre le correctif lui-même! La constante ici est le temps de se familiariser avec la base de code et constitue probablement la plus grande partie de la création du test ou de l’écriture directe du correctif!
Newtopian
1
J'aime cette réponse pour les bugs. Même si vous ne comprenez pas suffisamment le cadre pour soumettre un correctif, cela fait gagner un temps considérable à quelqu'un qui le fait. Il n’ya rien de moins susceptible de me faire résoudre un problème qu’un «bogue» vague et irréproductible qui pourrait être simplement un système mal configuré. Rien ne me fait sauter plus rapidement sur un problème qu'un simple cas de test, ce qui me permet d'essayer rapidement différents correctifs.
BobMcGee
11

"Si vous le faites, je l'inclurai" est bien mieux que "non".

Si vous êtes incapable de faire le travail pour une raison ou une autre, expliquez la situation en privé au responsable du projet.

Si vous ne souhaitez pas contribuer de quelque manière que ce soit à un projet open source que vous souhaitez utiliser, vous devriez alors rechercher un support commercial ou un autre produit commercial.

Yfeldblum
la source
5
Ainsi, seuls ceux qui contribuent directement ont le droit de se plaindre d’un bogue ou d’une fonctionnalité manquante? Bien, je suppose, mais cela signifie également que ni les contributeurs ni les utilisateurs n'ont le droit de se plaindre de l'absence d'adoption.
Aaronaught
@Aaronaught Non, ils ont le droit de se plaindre, mais il existe une limite au temps non rémunéré qu'un développeur peut investir dans un projet et il est important que les utilisateurs le reconnaissent. Dans mon propre travail, je réserve "j'accueillerais une demande de correctif / extraction" pour les fonctionnalités présentant des propositions de valeur médiocre pour les efforts et la communauté. Ou pour les cas où l'utilisateur insiste pour obtenir la fonctionnalité MAINTENANT et ne respectant pas le temps de quelqu'un d'autre ni les autres engagements du projet.
BobMcGee
10

"Merci pour la réponse."

Parce que:

  • À prix nul, la demande (demandes de fonctionnalités) dépasse l'offre (codeurs disponibles pour implémenter lesdites fonctionnalités).
  • Ragging sur tout ce qui est fourni gratuitement manque de classe IMHO.
  • C’est le but principal de FOSS: les gens apportent des légumes et de la viande pour enrichir la soupe aux pierres. Si je ne peux pas contribuer à quelque chose, je devrais être reconnaissant de pouvoir manger du tout et de ne pas me plaindre de ne pas manger mieux.
John
la source
9

Tu n'as rien à dire. Le fait même que les développeurs aient répondu indique suffisamment qu'ils savent déjà que le problème existe et que cela cause des difficultés pour (au moins certains) utilisateurs.

En fin de compte, rien de ce que vous dites ne convaincra le développeur de travailler pour vous s'il ne le souhaite pas.

Dean Harding
la source
9

Un bon projet open source aura un système de demande de bogue / fonctionnalité dans lequel les utilisateurs peuvent soumettre des bogues / fonctionnalités et d'autres peuvent voter sur eux afin que les responsables puissent identifier ce qui est important pour la communauté dans son ensemble. Cependant, le moyen le plus rapide de mettre votre fonctionnalité en place est de lui envoyer un correctif. Période ... aucun moyen de contourner cela.

Michael Brown
la source
8

Personnellement, je préférerais recevoir la réponse suivante: "C’est un problème connu, mais malheureusement, ce n’est pas un problème qui doit être résolu dans un avenir rapproché. Les développeurs travaillent sur d’autres problèmes. Il n’existe actuellement pas d’ETA."

La réponse "submit a patch" est très grossière, car elle suppose un certain nombre de choses:

  1. Tous les utilisateurs du programme sont des programmeurs ou tous les rapporteurs de bogues sont des programmeurs.
  2. Tous les programmeurs connaissent la langue du programme.
  3. Tous les programmeurs connaissent tous les types de problèmes qu'un programme peut rencontrer.
  4. Tous les programmeurs ont du temps libre pour travailler sur un projet open source.

Même si nous supposons que le fabricant de réponses «soumettre un correctif» connaît tout ce qui précède, cela donne simplement l’affirmation suivante: «X heures de mon temps valent plus que les ordres de grandeur que vous auriez à vous lever accélérer et résoudre le problème ".

Généralement, lorsque je reçois une réponse grossière d'un développeur lorsque je pose une question sur un problème que je rencontre ou que je soumets un bogue, je cesse d'utiliser ce programme.. Je n'utilise plus uTorrent (pas de source ouverte, mais le point reste inchangé), par exemple, parce que les réponses que j'ai obtenues sur leur forum de "support" étaient très grossières. J'ai soumis un problème que j'avais sur le forum de rapports de bugs. Le thread a été immédiatement verrouillé avec un lien vers un autre thread concernant un problème similaire, mais différent, dans un thread (qui était également verrouillé, bien sûr). Dans l'intervalle, j'ai ouvert un fil de discussion dans le forum de discussion générale pour demander si quelqu'un avait trouvé une solution de contournement au problème. Dans le temps qu'il a fallu pour sauvegarder ce fil et revenir en arrière et voir que mon premier fil avait été verrouillé, mon fil en général était verrouillé et mon compte de forum banni pour comportement perturbateur. J'ai désinstallé uTorrent et je n'y suis pas retourné depuis.

bacon
la source
Voulez-vous dire "je préférerais obtenir une réponse de" par opposition à "je préférerais ne pas recevoir"?
Andrew Grimm le
Merci pour le premier paragraphe en particulier. C'est incroyable de voir à quel point une telle base de courtoisie professionnelle peut être étrangère à beaucoup de gens. Que vous soyez payé ou non, la réponse appropriée est de reconnaître le problème et d'expliquer son statut (même si le statut est "différé").
Aaronaught
8

Rien que répondre à "envoyer un correctif" est une grossière OMI, mais quand même ... si vous utilisez un logiciel open source pour quelque chose de grave, vous devez être prêt à en prendre soin si le besoin s'en fait sentir.

Ce qui suit est basé sur un message de Jeremias Maerki (de la renommée Apache FOP):

Si quelque chose ne fonctionne pas pour vous, vous avez plusieurs options:

  • Ceci est open source: vous pouvez le réparer vous-même.
  • Si vous ne pouvez pas le réparer vous-même, vous pouvez attendre que quelqu'un ait du temps libre et pense que c'est amusant à mettre en œuvre.
  • Si cela ne se produit pas, vous pouvez trouver ou embaucher quelqu'un pour le faire à votre place.

Je pense que c'est une version complète très valide de la réponse "submit a patch".

Bertrand Delacretaz
la source
6

Chaque fois que je vois cela, je commence immédiatement à chercher un produit alternatif. Pour moi, c'est un signe dangereux que les responsables ne se soucient pas de leurs utilisateurs (mauvais si votre projet est utilisé partout) ou ont perdu tout intérêt pour le projet. Ces deux facteurs signifient généralement que le projet va mourir bientôt ou sera en proie à la stagnation, les développeurs refusant de faire avancer le projet.

(Notez que je ne dis pas que le tout premier rapport de bogue que vous voyez avec ce type de réponse est celui que vous générez. Vous devez examiner une tendance générale. Si la plupart des rapports de bogue se terminent par ce type de réponse, suivez ce conseil. c’est juste quelques-unes, alors ce sont probablement des demandes de fonctionnalités qui ne correspondent pas aux objectifs du projet ou qui sont extrêmement spécifiques à l’utilisation)

Comme @MainMa l'a dit, commencer à contribuer à un tout nouveau projet est très difficile. La plupart des développeurs ne comprennent pas cela, car ils travaillent sur le projet depuis des mois et des années et que cela leur semble logique. Cela peut parfois être une erreur honnête.

TheLQ
la source
3

Je plaisante à l'occasion que les logiciels libres peuvent être gratuits comme dans la bière, libres comme dans le discours ou libres comme si vous en avez pour votre argent.

Bien que je le dise en plaisantant (je travaille pour une entreprise qui utilise beaucoup de logiciels libres), mais je pense qu’il ya une vérité là-dedans - si vous voulez un support de niveau commercial, vous devez soit utiliser un logiciel commercial avec un contrat de support approprié, soit trouver un support. solution logicielle open source qui vous permet ce niveau de support (généralement par le biais d'une personne payée pour le fournir, mais éventuellement par le biais de votre organisation employant ou affectant une ressource de développement pour y travailler).

"Soumettre un correctif" est exaspérant, mais il met en évidence quelque chose au sujet du logiciel libre et cela devrait peut-être rappeler que le logiciel libre ne convient pas à tout le monde dans toutes les situations, du moins pas sans vous assurer que vous disposez d'un solide interne, payé pour ou par la communauté).

Nous pensons souvent à un logiciel gratuit comme dans la bière mais pas à la parole (c'est un freeware non ouvert). C’est peut-être un cas où nous devrions penser au logiciel aussi librement que dans la parole mais pas comme dans la bière.

Jon Hopkins
la source
2

Passez à une alternative bien entretenue.

D'après mon expérience avec des projets open source bien entretenus, si vous créez un rapport de bogue ou une demande de fonctionnalité bien défini, il y a de fortes chances qu'il soit implémenté.

vartec
la source
2
Les rapports de bogues et les demandes de fonctionnalités ne sont souvent pas bien définis. Mon expérience est que la compétence et le respect fonctionnent bien. En outre, une demande de fonctionnalité bien définie sera au mieux prise en compte. Cela peut être considéré comme une priorité faible ou peut être une chose que le groupe de projet ne souhaite pas explicitement (il existe de bons exemples dans la FAQ de PuTTY et une belle liste de demandes de fonctionnalités regroupées par catégories).
David Thornley
1

"Je ne peux travailler que sur une chose à la fois, mais je peux me plaindre de plusieurs choses à la fois. Je pense que les deux fonctions sont utiles." - akkartik sur ycombinator .

Vincent Scheib
la source
1

Je considère que quand on travaille sur un projet, en fournissant des versions et du support, un contrat de support tacite, implicite, entre le développeur et l'utilisateur commence à exister. Le développeur a assumé la responsabilité implicite de prendre en charge la base de code pour ses utilisateurs, y compris en ajoutant des fonctionnalités à la demande.

"Soumettre un patch", c'est à mon avis donner le doigt aux utilisateurs. C’est contextuel - parfois c’est tout simplement trop d’efforts à mettre en œuvre, parfois cela ruinerait le projet existant ou entraînerait une créatite chronique, ou une foule d’autres raisons. Mais en fin de compte, il dit: "Va te faire foutre, ne pas le faire". Ce qui, à mon sens, constitue, à un certain niveau, une violation de ce contrat tacite.

Paul Nathan
la source
Ce n'est pas un contrat à moins que les deux parties reçoivent quelque chose. Ce que veut généralement le projet, ce sont des rapports de bogue bien faits et des demandes de fonctionnalités souvent bien faites, et ce n’est pas tout ce qui est livré à la fin du contrat implicite.
David Thornley
1
@Aaronaught: Ils fournissent des tests gratuits uniquement s'ils déposent des rapports de bogues suffisamment détaillés pour fonctionner. J'ai vu ma part de mauvais rapports de bugs. Ils peuvent ou non fournir une bonne publicité. La plupart des utilisateurs de F / OSS ne rendent rien d’utile, ce qui est bien, mais ce n’est certes pas un aspect du contrat.
David Thornley
1
@ David: Souhaitez-vous s'il vous plaît arrêter d'essayer de limiter la conversation aux utilisateurs les plus difficiles / improductifs? Si nous allons généraliser, il faut que cette généralisation concerne l’ensemble des utilisateurs et des contributeurs, en tant que collectif; la libération au public vous amène à tous ces gens. En échange du bien que vous obtenez de beaucoup d'entre eux, vous rencontrez des problèmes de beaucoup d'autres. C'est la vie.
Aaronaught
1
@Aaronaught: Si nous allons généraliser, nous devons nous assurer de généraliser de manière appropriée. Je n'essaie pas de limiter la conversation aux pires utilisateurs, mais simplement de souligner qu'ils sont là. Une bonne partie de la conversation semble supposer que tous les utilisateurs sont des contributeurs, ce qui est tout simplement faux. Si nous ne parlons que des utilisateurs utiles au projet, il semble juste de ne parler que des membres de l'équipe de projet généralement polis.
David Thornley
2
@ David: Clairement, il y a des utilisateurs et des contributeurs extérieurs qui aident, ainsi que des problèmes. Il est clair que certains développeurs sont polis et professionnels dans la mesure où le bon sens et les bonnes compétences en matière de gestion du temps le permettent, ainsi que certains développeurs qui sont grossiers et peu professionnels par habitude. C'était une question sur la façon de traiter avec ce dernier groupe de développeurs. L'existence d '"utilisateurs problématiques" n'est pas contestée, mais il s'agit d'un faux pas qui n'a d'autre but que de faire dérailler la discussion en créant une situation contradictoire - alors laissons cela tranquille.
Aaronaught
1

Il y a plusieurs façons de le faire.

  • Proposition de fonction et vote. mais cela prend du temps.

  • Faites-vous embaucher par une entreprise qui en a besoin pour faire le correctif. Évidemment, c'est la meilleure solution, mais préparez-vous à collaborer avec le créateur du logiciel open source que vous souhaitez mettre à niveau.

  • Il est également important de savoir pourquoi la fonctionnalité n'est pas implémentée en premier lieu. Souvent, la fonctionnalité ne correspond pas au projet logiciel: l'équipe ne la souhaite pas, ne se sent pas nécessaire ou pense simplement que ce n'est pas la bonne façon de faire quelque chose. Dans ce cas, vous devez simplement créer le projet et le créer vous-même.

  • Utilisez un logiciel propriétaire qui fait ce que vous voulez.

  • N'oubliez pas que le logiciel POO facilite souvent le processus d'intégration d'une fonctionnalité.

  • Se lamenter sur une liste de diffusion, sur irc ou sur un forum ne fera que déranger les programmeurs et donnera des munitions aux promoteurs de logiciels libres.

jokoon
la source
0

Vous ne pouvez rien dire qui le fasse faire. Après tout, pourquoi devrait-il? À la demande d'un utilisateur? Ce n'est pas une raison suffisante.

Mais , si vous pouvez collecter un nombre raisonnable d'utilisateurs et donner des raisons rationnelles ("Je le veux" n'est pas une raison rationnelle.) Pourquoi cette fonctionnalité pourrait-elle être utile .

Bien que, il y a aussi un cas particulier qui doit être considéré. C'est un dev. est fatigué de développer l'application, souhaitant lentement l'abandonner (a d'autres choses à faire), et il abandonne donc lentement les demandes de fonctionnalités. À part essayer de le convaincre de publier le code, dans ce cas, vous ne pouvez pratiquement rien faire, même en ce qui concerne ce qui précède.

Tour
la source
Autrement, le développeur a suffisamment de demandes de fonctionnalités pour le garder occupé pendant le reste du siècle, aimerait inclure la vôtre, mais ne prévoit pas y arriver de si tôt.
David Thornley
@ David Thornley - Cela aussi.
Rook
0

Les projets open source en particulier sont favorables aux primes ou au financement du développement d'une fonctionnalité particulière, même si la nouvelle fonctionnalité ne parvient pas aux versions officielles.

De plus, oui, l'une des idées derrière la publication de l'open source est que tout le monde ait le droit et la responsabilité de faire sa propre contribution.

Avec des sources fermées, votre meilleure ressource consiste à rassembler auprès de la base d'utilisateurs un groupe important sur le plan statistique qui souhaite des solutions similaires à celles que vous souhaitez.

Apalala
la source
2
Le droit de contribuer, oui, mais la dernière fois que j'ai lu la GPL, cela ne mentionnait rien sur la responsabilité qui incombait aux utilisateurs finaux de faire leurs propres contributions. C'est un peu tiré par les cheveux, vous ne pensez pas?
Aaronaught
0

D'après mon expérience, cette réponse est généralement donnée si la demande de l'utilisateur ne correspond pas à l'objectif du projet. Cela se produit lorsque les gens pensent que vous allez mettre en œuvre tout ce qu'ils vous proposent, et même un peu plus - gratuitement, en open source et avec un bel avenir.

"Soumettre un correctif" est une réponse relativement grossière (et il faut bien sûr l'éviter. Surtout sous cette forme concise et précise. Il existe de nombreuses manières d'exprimer à peu près le même message - par exemple, "invitez" les utilisateurs à vous aider car vous n’avez pas le temps de le mettre en œuvre vous-même). Mais en l'état, c'est un indicateur clair de «cesser de perdre mon temps». En tant que tel, vous ne pouvez rien faire à ce sujet et il n’existe pas non plus de réponse «canonique».

La meilleure réponse à laquelle je puisse penser est de présenter un correctif . En supposant que votre correctif fonctionne, vous avez au moins prouvé que l’idée n’est pas totalement irréaliste. Habituellement, cela signifie que les responsables du projet réexamineront la proposition.

Alexander Gessler
la source
1
Je ne pense pas qu'aucun développeur devrait répondre "soumettre un correctif" concernant une demande qui ne correspond pas à l'objectif du projet. C'est plus malhonnête que grossier. Soit le logiciel devient gonflé et le développeur vous en veut, soit il n'accepte pas le correctif et vous fait perdre votre temps. Ce dernier est plus probable. Le développeur devrait vraiment dire honnêtement "Nous ne voulons pas changer cela parce que ____" et en finir avec cela.
Rei Miyasaka le
@Rei Miyasaka: Personnellement, je serais furieux si je recevais "envoyer un patch", si je faisais le travail pour créer un patch de bonne qualité, et qu'on me disait ensuite qu'ils ne voulaient pas la fonctionnalité de toute façon.
David Thornley
@ David Ouais hein? Je jetterais une chaise ou deux.
Rei Miyasaka le
0

"soumettre un correctif" est un moyen légitime de chercher des idées qui ne correspondent pas aux objectifs du projet. Il est probablement préférable à long terme de simplement vous dire que l'idée est nulle ou que vous essayez d'utiliser le projet pour quelque chose qui dépasse le cadre prévu, mais "hé, si vous pensez que ce que vous demandez est si trivial, pourquoi ne pas Tentez-vous de l’intégrer dans notre base de code existante "est parfois approprié.

Si cela est mineur et vraiment utile aux utilisateurs prévus du projet, soumettez simplement le rapport de bogue, décrivez clairement le problème, indiquez les étapes à reproduire, indiquez que vous utilisez la version nocturne en cours, et ne le laissez pas.

Ce qui peut sembler être un simple changement mineur qui aiderait des tonnes d'utilisateurs peut en réalité être une douleur énorme que personne n'utiliserait à part vous. C'est le meilleur cas pour "soumettre un patch".

Il est également possible que vous ayez rencontré un cas tel que le réputé responsable de la glibc qui semble penser que son système est l’univers, que son interprétation des spécifications est la parole de dieu, et c’est tout de combien de personnes préféreraient autrement.

Kevin Peterson
la source
Je ne pense pas que quiconque choisirait de poser cette question s’ils savaient que le changement serait une énorme douleur dans le cul utilisé par une seule personne. Donc, au lieu de "soumettre un patch", pourquoi ne pas expliquer poliment et brièvement pourquoi c'est un si gros problème et qu'il ne peut être fait immédiatement.
M. Shickadance
2
"Soumettre un correctif" constitue un véritable coup d'éclat, car il est possible que quelqu'un soumette un correctif. Il devrait être réservé aux non-gentils à faible priorité.
David Thornley
0

Je suggérerais de créer un projet pour implémenter la fonctionnalité sur des sites tels que RentACoder / ELance / etc, et de publier à ce sujet sur le forum du projet open source original. Tous les programmeurs des projets open source, y compris l'auteur, bénéficient désormais d'un incitatif financier pour prendre en compte votre requête.

Renji Panicker
la source
-1

Je me suis inscrit juste pour répondre à cette question.

Une réplique est-elle nécessaire? cette réponse est généralement utilisée lorsque le développeur est au courant du problème mais ne le considère pas aussi important.

Je vais vous donner un exemple en direct. Ubuntu a abandonné le support systray (mais peut être contourné par une liste blanche d'une application) et a ajouté de nouveaux indicateurs d'application. Certaines applications telles que jupiter s'appuyaient sur le support systray. Le développeur a donc parlé de workaournd au lieu d'ajouter le support app-indicateur. J'ai donc demandé au développeur d'ajouter le support app-indicateur, la réponse étant "Envoyez-nous des correctifs". en demandant la raison pour laquelle ils ont choisi de ne pas mettre cela en œuvre. il y avait ça

Je n'ai aucun intérêt à passer mon temps à construire du support pour une bibliothèque que je n'utiliserai jamais, simplement parce que quelqu'un qui a beaucoup d'argent l'exige, en listant ma capacité des applications à fonctionner correctement sur sa distribution Linux simplement parce qu'il le peut.

Si c’était un problème technique, j’agirais probablement, mais c’est une manoeuvre purement politique, alors non, je ne le pense pas.

Non, je vais juste la mettre en liste blanche

C'est suffisant. le développeur a des raisons de ne pas implémenter une fonctionnalité mais est prêt à accepter les correctifs. ce n'est pas vraiment impoli et offensif, il n'y avait donc pas besoin d'une réplique.

ligne de fond: la réplique canonique serait de soumettre le correctif mais si vous ne pouvez pas, il n’est pas nécessaire de répliquer.

Lincity
la source
-1

Commencez une prime pour la fonctionnalité que vous souhaitez.

Vous pouvez également acheter le produit qui prétend faire exactement ce que vous voulez et abuser de son personnel de soutien lorsque vous découvrez que le marketing ne correspond pas à vos attentes.

CyberFonic
la source
-2

Le mieux que je puisse penser est "tu crains".

Désolé, cela n’est évidemment pas très utile, mais je pense que cela n’est que l’une des situations malheureuses dans lesquelles l’utilisateur est complètement foutu. Un appel brutalement honnête à la conscience du développeur est un dernier effort.

Vous pouvez essayer de l' offre ( toux ) « dons » d'avoir votre problème à résoudre, mais je crains qu'une telle pratique si commune faite conduirait à une perte d'intégrité vraiment mauvais dans l'industrie, que des corrections de bugs ne doivent jamais être mis à profit, que ce soit pour Logiciel "gratuit" ou commercial.

Rei Miyasaka
la source