Was ist die kanonische Erwiderung auf "Es ist Open Source, Reiche einen Patch ein"? [geschlossen]

215

Die Gefahr, jemals eine Funktion für ein Produkt vorzuschlagen, insbesondere Open Source, besteht darin, dass Sie die Antwort erhalten: "Warum machen Sie das nicht?".

Das ist gültig und es ist cool, dass Sie die Änderung selbst vornehmen können. Aber wir wissen praktisch, dass sich Produkte oft verbessern, wenn Programmierer auf die Stimme der Benutzer hören - auch wenn diese Benutzer andere Programmierer sind. Die effiziente Möglichkeit, diese Änderungen vorzunehmen, besteht darin, dass bereits jemand an dem Projekt arbeitet, der die Idee aufgreift und umsetzt.

Es gibt einige gebräuchliche Begriffe, die sich auf Softwareentwicklungsprobleme beziehen. zB Bikeshedding . Gibt es einen gebräuchlichen Begriff, der im Wesentlichen antwortet: "Ja, ich weiß, dass ich so gut wie alles auf der Welt ändern kann - sogar geschlossene Quellen. Ich könnte eingestellt werden und diesen Code schreiben. Aber in diesem Fall mache ich nur eine Beobachtung, die in der Tat nützlich sein kann für einen anderen Programmierer, der bereits gut geeignet ist, um diese Änderung einfach vorzunehmen - oder einfach nur Möglichkeiten allgemein zu diskutieren. "

[ps (ein paar Tage später) - Ich hätte darauf hinweisen sollen, dass "einen Patch einreichen" oft mit schiefem Humor gesagt wird, und ich suche eine angemessene witzige Antwort.]

Vincent Scheib
quelle
16
Ich wünschte, ich könnte das mehr als einmal befürworten! (Und das von jemandem kommt, der hat . Patches zu einer Handvoll verschiedenen Projekte eingereicht und sie akzeptiert bekommen Diese Haltung Sie beschreiben , ist einfach nur ärgerlich!)
Mason Wheeler
62
Ich nehme an "Wie sehe ich aus, ein arbeitsloser Code-Affe? Ich habe ein Leben!" ist keine akzeptable Retorte ;-)
Steven A. Lowe
12
Nach meiner Erfahrung erfolgt die Antwort auf die Frage nach dem Senden eines Patches normalerweise, nachdem der Entwickler bereits erklärt hat, warum das Hinzufügen des Features nicht praktikabel wäre.
user16764
7
@Steven, hängt davon ab, ob Sie die Beleidigung noch übertreffen oder sie tatsächlich dazu bringen möchten, das zu tun, was Sie brauchen. Ich glaube, es ist keine optimale Strategie, wenn Sie die letztere wollen.
12
@orokusaki: Oder D) Sie halten das Feature für weniger wertvoll als andere Features, an denen sie arbeiten könnten, und sie haben begrenzte Ressourcen.
David Thornley

Antworten:

115

Dies ist ein schwieriger Punkt: Da der Benutzer weder direkt noch indirekt für ein Produkt bezahlt, kann er die Implementierung einer Funktion nicht verlangen. Es ist nicht so, als ob Sie ein Stakeholder oder ein direkter Kunde wären, der das Produkt bestellt hat, und nicht einmal ein Endverbraucher eines kommerziellen Produkts.

Dies wird gesagt, „einen Patch einreichen“ ist keine gültige Antwort. Das ist nicht höflich. Das ist nicht richtig. Auch für ein Open Source Produkt. "Submit a Patch" ist die Kurzversion von:

"Es ist uns egal, ob Sie unser Produkt mögen oder nicht. Ändern Sie es, wenn Sie möchten, aber stören Sie uns nicht mit Ihren Kundenwünschen."

Was ist mit dem Einreichen eines Patches?

Nun, es ist nicht so einfach. Es zu tun:

  • Sie müssen die Sprache (n) kennen, die im Open Source-Projekt verwendet werden.

  • Sie müssen in der Lage sein, den Quellcode aus der Versionskontrolle zu laden, um ihn ändern zu können.

  • Sie müssen alle korrekten Versionen von Build-Abhängigkeiten installiert haben (einschließlich Laufzeitbibliotheken und Build-Tools).

  • Sie müssen in der Lage sein, diesen Quellcode zu kompilieren , was in einigen Fällen nicht so offensichtlich ist. Insbesondere wenn ein großes Projekt einige Stunden benötigt, um 482 Fehler und Tausende von Warnungen zu kompilieren und anzuzeigen, ist es möglicherweise mutig, nach der Quelle dieser Fehler zu suchen.

  • Sie sollten sehr gut verstehen, wie das Projekt ausgeführt wird , wie der zu verwendende Codierungsstil ist, wie Unit-Tests usw. ausgeführt werden ), kann es sehr schwer sein.

  • Sie müssen sich an das Projekt und an die Gewohnheiten der Entwickler anpassen, die sich aktiv am Projekt beteiligen. Wenn Sie beispielsweise .NET Framework 4 täglich verwenden, das Projekt jedoch .NET Framework 2.0 verwendet, können Sie weder LINQ noch Codeverträge oder andere Tausende neuer Funktionen der neuesten Versionen des Frameworks verwenden.

  • Ihr Patch muss akzeptiert werden (es sei denn, Sie nehmen die Änderung nur für sich selbst vor, ohne die Absicht, sie mit der Community zu teilen).

Wenn Sie beabsichtigen, sich aktiv an dem Projekt zu beteiligen, können Sie all diese Dinge tun und Ihre Zeit dafür investieren. Wenn auf der anderen Seite nur ein nerviger kleiner Fehler oder eine einfache Funktion fehlt, die Tage, Wochen oder Monate damit verbringt, das Projekt zu studieren, ist es einfach unvernünftig, die Arbeit selbst in wenigen Minuten zu erledigen, es sei denn, Sie mögen es.

Gibt es also eine kanonische Erwiderung zu "Es ist Open Source, Reiche einen Patch ein"? Ich glaube nicht Entweder erklärst du der Person, dass sie unhöflich ist, oder du hörst einfach auf, mit ihr zu reden.

MainMa
quelle
9
Das klingt so, als ob es von jemandem geschrieben wurde, der keine Erfahrung in der Pflege eines Open Source-Projekts hat.
Rein Henrichs
46
@Rein: Das Verwalten eines Open Source-Projekts unterscheidet sich nicht vom Verwalten eines anderen Projekts. Sie haben Kunden. Wenn Sie diese Kunden ignorieren, geben sie Ihnen kein wertvolles Feedback mehr und gehen für ihre Lösungen woanders hin. Vielleicht ist das in Ordnung für Open-Source-Leute, aber ich würde gerne wissen, ob ich für die Behebung von Fehlern an einer Open-Source-Software voll verantwortlich sein würde, da ich dann zweimal darüber nachdenken müsste.
Robert Harvey
17
@Rein: Nun, ich habe bis jetzt schon zweimal gehört, dass wir nicht wissen, wovon wir reden. Vielleicht können Sie uns aufklären, was?
Robert Harvey
8
@ Rein Henrichs: Ihre ersten beiden Kommentare sind "ad hominem" -Angriffe. Wenn es Unterschiede zwischen den beiden gibt, sagen Sie, was sie sind, anstatt zu sagen, dass andere nichts wissen.
Andrew Grimm
13
Ich vermute, dass die Absicht lautete, "ein Open-Source-Projekt aufrechtzuerhalten, unterscheidet sich nicht von anderen Projekten, wenn es darum geht, Kundenfeedback zu hören und ihren guten Willen zu wahren." Wenn ja, bin ich bereit, es fallen zu lassen, aber als jemand, der mehrere FOSS-Projekte mit einer Handvoll bis zu Hunderten von Mitwirkenden unterhalten hat, finde ich die ursprüngliche pauschale Aussage "falsch".
Rein Henrichs
79

Die kanonische Retorte besteht darin, einen Patch einzureichen.

wnoise
quelle
47
Oder noch besser, um zu sagen: "Ich habe es bereits vor sechs Monaten getan. Wann werdet ihr herumkommen, um es zu überprüfen und zu begehen?"
Bob Murphy
14
Normalerweise mag ich keine kurzen Antworten, aber dies ist die einzige Möglichkeit zu antworten, die garantiert zum gewünschten Ergebnis führt. Sie gaben klar und deutlich den bestmöglichen Weg an, um Ihr Ziel zu erreichen. Warum mit irgendeiner geringeren Lösung rumalbern?
19
-1 Open Source Arschloch Antwort. Nicht nützlich. (Entschuldigung.) Es gibt keine kanonische "Retorte". Die beste Antwort (vorausgesetzt, das OP kann nicht einfach einen Patch einreichen, was meiner Meinung nach in diesem Fall eine vernünftige Annahme ist) ist eine der folgenden: (1) "Ich habe nicht die Fähigkeiten oder Ressourcen, um einen Patch zu generieren Link zu dieser Frage] ", (2) Eyeroll, keine Antwort, Verwendung des Werkzeugs im aktuellen Zustand oder (3) Suche nach einem besseren Werkzeug.
JohnL4
1
Es muss nicht unbedingt ein Patch sein. Es lohnt sich auch, detailliertes und verfeinertes Feedback zu geben. Das heißt nur: Erwarten Sie nicht, dass ich meine Zeit investiere, um Ihren spezifischen Bedarf zu decken, wenn Sie nichts zu bieten haben.
Evan Plaice
67

Dies ist die Standardantwort, wenn Entwickler nicht glauben, dass sie in einem vernünftigen Zeitrahmen etwas tun können, aber sie wurde wiederholt angesprochen.

Es ist am unfairsten, wenn es wiederholt zur Sprache gebracht wird, aber die Person, die es zuletzt erwähnt hat, weiß das nicht und bekommt sofort die Meldung "Wir nehmen Patches dafür". In diesem Fall hat der Betreuer die Diskussion satt, aber der Benutzer denkt, dass es sich um ein neues Thema handelt. Auf jeden Fall sollten Sie es höchstwahrscheinlich nicht persönlich nehmen, wenn Sie sofort "Patches nehmen", sondern in den Archiven und im Bug Tracker nachlesen, um weitere Informationen zu diesem Problem zu erhalten.

Wenn Sie wiederholt selbst eine Anfrage stellen, ist das "Nehmen von Patches" möglicherweise eine relativ höfliche Abzocke im Vergleich zu einigen weniger höflichen Alternativen ...

Und dann gibt es natürlich unhöfliche Betreuer, die "Patches nehmen" sagen, ohne jemals jemandem eine Erklärung zu geben, aber ich würde sagen, das ist eine Minderheit.

Wenn Sie jemals ein Open Source-Projekt mit vielen Benutzern unterhalten haben, wissen Sie, dass es 100-mal mehr Anfragen gibt, als die Betreuer jemals erhalten könnten. oder würde eine Menge anderer Benutzer stören oder einen anderen Fehler aufweisen, der nur sichtbar ist, wenn man das Projekt und die Codebasis global versteht. Oder manchmal gibt es nur Urteilsforderungen, und es braucht zu viel Zeit, um sich immer wieder zu streiten.

Die meisten Nicht-Open-Source-Unternehmen geben Ihnen überhaupt keinen Zugriff auf die Entwickler, und Sie erhalten lediglich die stille Behandlung oder eine höfliche, aber gefälschte Geschichte vom Kundensupport. Zumindest in Open Source haben Sie also einige Optionen (zahlen Sie jemanden, der das Feature codiert usw.), und während Entwickler vielleicht unhöflich sind, geben sie zumindest klare Antworten. Ich hätte lieber "nein" als das übliche "es steht auf unserer Roadmap ... [2 Jahre später] ... es steht immer noch auf unserer Roadmap", was ich von einer Reihe von Anbietern bekommen habe ...

Ich glaube also nicht, dass es eine Retorte gibt. Vielleicht ist der Open-Source-Betreuer nur sehr beschäftigt, vielleicht sind sie ein Idiot, aber so oder so haben sie wahrscheinlich einen schweren Job, und eine Debatte darüber, wer das letzte Wort hat, führt nirgendwo hin. Das Beste, was Sie tun können, ist auf irgendeine Weise beizutragen und zu versuchen, konstruktiv zu sein.

Möglicherweise handelt es sich nicht um Code, aber möglicherweise gibt es eine Menge Analyse- und Dokumentationsszenarien für Benutzer, die Sie durchführen können. Als ich den GNOME-Fenstermanager gewartet habe, war es oft hilfreich, ein Problem global unter Berücksichtigung aller Benutzer zu analysieren und die Probleme und Vor- und Nachteile sowie die Auswirkungen aus globaler Sicht aufzuschreiben.

(Stattdessen war es üblich, zu brennen, als ob sie der einzige Benutzer wären, der etwas ausmachte, und es gab keine Kompromisse. Und obwohl das großartig war und ein Datenpunkt war, gelang es mir oft, höflich zu bleiben oder ihr Problem zu lösen.) Flammen lässt nichts schneller passieren, sondern verwirrt Emotionen und verschwendet Zeit.

Havoc P
quelle
4
@Aaronaught Ich habe bereits Hunderte von Open Source-Projekten bearbeitet und DIY als Standardantwort nicht bemerkt. Es ist eine Antwort auf bestimmte Arten von Anfragen.
Havoc P
2
Alles, was ich sage, ist, ich denke, es gibt einen Grund, warum ein Betreuer ein Thema (oder eine Person) ein wenig satt hat, bevor er "Patches nehmen" sagt bekam diese Antwort. Es ist meine Erfahrung, fwiw. Wenn es hier um Fälle geht, in denen es keinen Grund gibt, das Thema oder die Person satt zu haben, ist es für den Betreuer wahrscheinlich keine gute Sache, "Patches zu nehmen". Menschen machen Fehler. Ich sage immer noch, ich bezweifle, dass eine Retorte (oder eine Metadiskussion wie diese) helfen wird, aber manchmal könnte konstruktiv eingegriffen werden.
Havoc P
5
Auch wenn es mehr oder weniger höflich formuliert werden kann, wenn ein Betreuer einen Arbeitsstau in seinem Kopf hat, haben sie wahrscheinlich eine Sache, die sie für sich selbst erledigen können, und zwar für alle 100 Dinge, für die sie einen Patch nehmen würden , weil sie das wollen würden Feature; und dann gibt es noch eine andere Kategorie von Änderungen, die sie ablehnen würden, selbst wenn jemand anderes die Arbeit erledigen würde. Es muss also eine Möglichkeit geben, zu kommunizieren: "Ich würde diese Änderung annehmen, aber ich habe nicht vor, sie selbst vorzunehmen." Einige Leute hier scheinen das Gefühl zu haben, dass "Sicher, dass es richtig läuft" die einzig akzeptable Antwort ist. Aber "Patches zu diesem Thema nehmen" ist eine echte Kategorie.
Havoc P
2
@Aaronaught das klingt nach guten Formulierungen. Ich denke, dass oft keine Beleidigung oder Unhöflichkeit mit "dafür würden wir einen Patch nehmen" gemeint ist, aber Programmierer sind in der Regel nicht die emotional empfindlichsten Typen, stürzen möglicherweise durch E-Mails und der Ton wird nicht sehr gut durch Text weitergeleitet. es ist also leicht, als kurz zu bezeichnen.
Havoc P
2
Tatsächlich unterscheidet sich "wir würden einen Patch dafür nehmen" in zwei subtilen, aber wichtigen Punkten: (1) Die Verantwortung liegt nicht direkt beim Benutzer , und (2) es wird anerkannt, dass die Anfrage ernsthaft geprüft wurde, obwohl sie nicht beantwortet wurde umgesetzt. Obwohl das Nettoergebnis im Wesentlichen dasselbe ist, ist es eine weitaus humanere Antwort. (Trotzdem würde es nicht schaden, das
Implizierte
43

Der Grund, warum Sie diese Antwort erhalten, ist nicht, dass die Betreuer Idioten sind, sondern dass Sie sie nicht ausreichend davon überzeugt haben, dass sie an Ihrem Feature für Sie arbeiten .

Die beste Antwort ist, einen Dialog über den Wert Ihres Features für die gesamte Community zu beginnen , um zu sehen, ob Sie sie davon überzeugen können, ihre Meinung zu ändern. Vielleicht haben sie recht und wissen mehr über die Bedürfnisse ihrer eigenen Gemeinde als Sie - aber andererseits vielleicht auch nicht.

Wenn das Feature nur für Sie wertvoll und für die Community von geringem bis gar keinem Wert ist, finde ich, dass Geld ein hervorragender Motivator ist, während es sich über ihre Haltung nicht beschwert.

Rein Henrichs
quelle
15
Natürlich, vielleicht sind sie Idioten. Diese Antwort allein ist kein sehr genauer Indikator, da sie auch von Nicht-Zuckern verwendet wird, wenn der Fragesteller ein Zuck ist.
Rein Henrichs
4
Ich möchte auch hinzufügen, dass Sie in Ermangelung von Geld häufig Sachleistungen gegen Arbeit eintauschen können: Helfen Sie, eine ausgelastete Problemwarteschlange zu durchsuchen, im IRC-Kanal zu bleiben und Support zu leisten, Patches zu testen oder Dokumentation zu schreiben. Open Source-Projekte verfügen nur über begrenzte Ressourcen und müssen diese optimal nutzen. Das Hinzufügen eines Features ist sinnvoll, wenn es für genügend Personen wichtig ist oder für Personen, die genug tun / geben. Wenn Ihr Fall nicht der erstere ist, machen Sie ihn zum letzteren.
HedgeMage
2
Ehrlich gesagt, der beste Weg, einen Entwickler zu überzeugen, besteht darin, ihm zu zeigen, wie sehr seine Nutzerbasis das Feature möchte. Bugtracker mit Voting, Forenthreads usw. sind dafür sehr gut geeignet und werden in vielen Open-Source-Projekten verwendet.
ProdigySim
4
Wenn Personen eine RTFM oder DAFS als Antwort oder eine -1 für SE erhalten, liegt dies ebenfalls daran, dass der Fragesteller den Beantworter vom Nutzenversprechen der Beantwortung seiner Frage für sie nicht ausreichend überzeugt hat . Ich bin sicher, dass viele von Ihnen sich auf dieses Gefühl beziehen können.
Rein Henrichs
1
@Walter Yep, aus diesem Grund habe ich vorgeschlagen, die Person von "dem Wert Ihres Features für die gesamte Community" zu überzeugen.
Rein Henrichs
31

Was ist die kanonische Erwiderung auf "Es ist Open Source, Reiche einen Patch ein"?

Es gibt keine vernünftige Antwort, die einen Unterschied machen könnte. Der Versuch, Freiwillige zu überreden, etwas zu tun, was sie nicht vorhaben, ist Zeitverschwendung ... oder schlimmer.

Ihre Möglichkeiten sind:

  • Mach, was die Antwort nahelegt. dh implementieren Sie das Feature und senden Sie es als Patch. Es heißt "etwas zurückgeben".

  • Finden Sie jemanden, der bereit wäre, die Funktion für Sie für echtes Geld zu implementieren. Es kann sich um das Projekt selbst handeln (z. B. als Gegenleistung für Sponsoring), um jemanden, der mit dem Projekt in Verbindung steht, oder um einen zufälligen "Coder for Hire".

  • Finden Sie ein alternatives Produkt.


Wenn Sie diese Antwort erhalten haben, als Sie einen "hilfreichen" Vorschlag gemacht haben, überlegen Sie, wie Sie möglicherweise reagiert haben, wenn Sie in seinen Schuhen stecken. Wie würden SIE beispielsweise reagieren, wenn Sie der Meinung wären, dass sich der Vorschlag nicht lohnt / durchdacht / verständlich / usw., aber nicht die Zeit oder die Geduld hatte, sich auf eine langwierige Debatte einzulassen?


Ich war an einem langjährigen Open-Source-OS-Projekt beteiligt, und eines der nervigsten Dinge sind die Leute, die in der "Erdnussgalerie" sitzen und Ihnen eine Reihe von Vorschlägen liefern, wie Sie Dinge "besser" machen können:

  • unvollständig, unverständlich oder geradezu unsinnig sind,
  • sind unerprobte Ideen mit objektiv geringen Erfolgschancen,
  • eine enorme Menge an Aufwand zur Implementierung erfordern würde, und / oder
  • stehen im Widerspruch zu den erklärten Zielen des Projekts.

Oft ist es die beste Antwort, die Person gezielt aufzufordern, sich an dem Projekt zu beteiligen ... und zu hoffen, dass sie den Hinweis auf "Aufgeben oder den Mund halten" versteht. Leider verstehen die Ärgerlichsten nicht einmal einen Hinweis.

Natürlich besteht die andere Antwort auf solche Leute darin, überhaupt nicht zu antworten oder sie vollständig zu ignorieren.

Stephen C
quelle
7
"Wie würden SIE reagieren, wenn Sie der Meinung wären, dass sich der Vorschlag nicht lohnt / durchdacht / verständlich / usw." - genau wie jeder andere Fachmann reagiert. "Können Sie erklären / einige Beispiele geben, wonach Sie fragen?" oder "Können Sie mir etwas Hintergrundwissen darüber geben, warum Sie glauben, dass Sie diese Funktion benötigen?" oder "Was wäre, wenn wir stattdessen dieses andere Ding machen würden?" oder wie wäre es einfach mit "Vielen Dank für Ihren Vorschlag, wir werden ihn für eine zukünftige Veröffentlichung in Betracht ziehen." Dies sind grundlegende zwischenmenschliche Fähigkeiten, keine Raketenwissenschaft.
Aaronaught
12
@Aaronaught - Entschuldigung, aber du verstehst es nicht. Der typische Open-Source-Entwickler hat nicht die Zeit, höfliche, aber letztendlich sinnlose Diskussionen zu führen, um das Ego seiner "Kunden" zu schärfen. Das heißt, man gibt vor, sich zu kümmern, wenn ein halb intelligenter Mensch herausfinden kann, dass alles eine Fassade ist. Und um ehrlich zu sein, ich finde diese Art von Ego, das Höflichkeit streichelt, bevormundend ... und beleidigender, als wenn man mir direkt sagt, dass es keine Chance gibt, dass sie XYZ implementieren.
Stephen C
6
@kurige - tatsächlich, wenn die fraglichen Personen Patches einreichten, würden sie ENDGÜLTIG in Betracht gezogen. Das Problem ist, dass die fraglichen Leute "alle Münder" sind; dh kein Interesse daran, sich anzustrengen.
Stephen C
10
Weil der typische Open-Source-Entwickler bereits einen Job hat und seine Open-Source-Entwicklung zum Spaß macht. Zu tun, was andere von Ihnen erwarten, ist Arbeit. Das zu tun, was du willst, macht Spaß.
ProdigySim
8
@Aaronaught: Ist es notwendig, mit vielen Idioten respektvoll umzugehen? Bei einem öffentlichen Dienst wird es Menschen geben, die unangemessene Forderungen stellen, oft in beleidigender Form. Der Umgang mit unhöflichen Dummköpfen kann ein echtes Problem sein. Eine Verpflichtung, ihnen gegenüber respektvoll zu sein, würde viele Leute aus dem F / OS-Geschäft vertreiben, und das wäre ein Verlust für alle.
David Thornley
20

Die Antwort wäre angemessen, wenn Sie und der betreffende Programmierer gleich wären und die Codebasis, die Sprache und alle anderen für diese bestimmte Sache relevanten Dinge, auf die Sie hinweisen, in etwa gleich gut kennen.

Sie sind nicht gleichberechtigt (oder Sie hätten es wahrscheinlich einfach getan), daher würde ich eine angemessene Retorte vorschlagen:

"Ich kann es auf keinen Fall so schnell und gut machen wie du. Deshalb habe ich dich gebeten, mir zu helfen. Bitte!"

Ich glaube, dass es gegen die fundamentale menschliche Natur verstößt, zu sagen: "Oh, ja, diese Sache, für die ich lange Zeit gearbeitet habe und die ich wirklich gut kann, ist so einfach, dass jeder von der Straße hereinkommen und so gute Arbeit wie möglich leisten kann Ich kann ".

user1249
quelle
Aber das ist nicht wirklich das, was sie sagen. Sie sagen: "Das, was Sie wollen, ist nicht das, was die Community will. Wir sind also nicht wirklich daran interessiert, daran zu arbeiten. Wir akzeptieren möglicherweise einen Patch, wenn Sie daran arbeiten möchten." Implizit bedeutet dies: "Wir können auch unsere Meinung ändern, wenn die Community dies wünscht." Denken Sie daran, dass "Ich möchte, dass Sie mir helfen " gegen die grundlegende Natur von Open-Source-Projekten verstößt, bei denen (um die volle Kraft meiner Star-Trek-Nerderie zum Tragen zu bringen) das Wohl der Vielen immer das Wohl der Wenigen überwiegt.
Rein Henrichs
Nun, es sei denn, diese wenigen haben historisch gesehen viel Geld.
Rein Henrichs
2
@Rein, nein, was sie sagen ist, dass SIE es nicht tun wollen. Alles, was "die Gemeinschaft will", ist nur ein Strohmann. Der springende Punkt ist, dass einer von der GEMEINSCHAFT darum bittet.
1
"Es ist äußerst unhöflich, das Schreiben eines Patches vorzuschlagen, wenn Sie vorher nicht wissen, ob Sie es für Ihr Produkt in Betracht ziehen würden." Einverstanden. Wie gesagt, aus diesem Grund verwende ich diese Antwort nicht. Ich kann damit allerdings sympathisieren. "Wenn Sie aufrichtig meinen, dass" einen Patch einreichen "dazu gedacht ist, Leute zum Schweigen zu bringen, anstatt Arbeit zu delegieren, stimmen Sie zu, dass dies von einem Community-Mitglied und nicht von einem Entwickler verlangt wurde." Ich bin mir nicht sicher, was du hier sagst, sorry.
Rein Henrichs
1
@ Thorbjørn Ah ja. Tatsächlich denken die mir vertrauten Open-Source-Betreuer auf keinen Fall so. Tatsächlich geben wir uns alle Mühe, Entwicklerrichtlinien und -dokumentationen bereitzustellen, damit die Leute das Projekt und die Konventionen kennenlernen, um genau deshalb dazu beizutragen, weil wir uns der Qualifikationslücke bewusst sind. Zum Beispiel rubini.us/doc/en/contributing
Rein Henrichs
16

Die kanonische Retorte soll das Projekt verzweigen.

user16764
quelle
8
oder einen Patch einreichen
Kamil Szot
2
Welchen guten Willen bringt dir Gabeln?
1
@Thorbjorn: Jeder könnte ab und zu eine gute Gabel gebrauchen. Sogar eine schade Gabel.
user18014
15

Die kanonische Antwort auf "Patch einreichen" lautet:

"Ich habe nicht die Fähigkeiten, die Erfahrung oder die Zeit, die ich benötige. Kannst du mir bitte sagen, wohin ich die Bierkisten an den Mann schicken soll, der das für mich tun kann?"

gbjbaanb
quelle
13

Reichen Sie einen umfassenden Testfall ein .

Alecco
quelle
1
Ich mag diesen aber, dies würde oft länger dauern als das Einreichen des Patches selbst! Die Konstante hier ist die Zeit, um sich mit der Codebasis vertraut zu machen, und ist höchstwahrscheinlich der größte Teil der Erstellung des Tests oder der direkten Erstellung des Patches!
Newtopian
1
Ich mag diese Antwort für Bugs. Selbst wenn Sie das Framework nicht ausreichend verstehen, um eine Korrektur einzureichen, spart dies enorm viel Zeit für jemanden, der dies tut. Es gibt nichts, was mich weniger dazu bringt, ein Problem zu beheben, als einen vagen und nicht reproduzierbaren "Bug", der einfach ein falsch konfiguriertes System sein könnte. Es gibt nichts, was mich dazu bringt, schneller auf ein Problem zuzugehen als ein einfacher Testfall, sodass ich schnell verschiedene Korrekturen ausprobieren kann.
BobMcGee
11

"Wenn Sie es tun, werde ich es einschließen" ist viel besser als "nein".

Wenn Sie die Arbeit aus dem einen oder anderen Grund nicht ausführen können, erklären Sie den Umstand dem Projektbetreuer unter vier Augen.

Wenn Sie nicht bereit sind, in irgendeiner Weise zu einem Open-Source-Projekt beizutragen, das Sie verwenden möchten, sollten Sie stattdessen nach kommerzieller Unterstützung oder einem anderen kommerziellen Produkt suchen.

yfeldblum
quelle
5
Also haben nur diejenigen, die direkt dazu beitragen, das Recht, sich über einen Fehler oder eine fehlende Funktion zu beschweren? Gut, denke ich, aber das bedeutet auch, dass weder die Mitwirkenden noch die Benutzer ein Recht haben, sich über mangelnde Adoption zu beschweren.
Aaronaught
@Aaronaught Nein, sie haben das Recht, sich zu beschweren, aber es gibt eine Begrenzung für die unbezahlte Zeit, die ein Entwickler in ein Projekt investieren kann, und es ist wichtig, dass Benutzer dies erkennen. In meiner eigenen Arbeit behalte ich mir "Ich würde einen Patch / Pull-Antrag begrüßen" für Funktionen vor, die miesen Aufwand / Community-Wertbeiträge haben. Oder für den Fall, dass der Benutzer darauf besteht, dass er die Funktion JETZT erhält und die Zeit eines anderen oder andere Projektverpflichtungen nicht beachtet.
BobMcGee
10

"Danke für die Antwort."

Weil:

  • Bei einem Preis von Null übersteigt die Nachfrage (Anforderungen nach Funktionen) das Angebot (verfügbare Codierer zum Implementieren dieser Funktionen).
  • Wenn man auf irgendetwas herumwirbelt, das kostenlos zur Verfügung gestellt wird, fehlt IMHO die Klasse.
  • Das ist der springende Punkt bei FOSS: Leute, die selbst Gemüse und Fleisch mitbringen, um die Steinsuppe zu nähren. Wenn ich nichts beitragen kann, sollte ich dankbar sein, dass ich überhaupt essen kann, und mich nicht darüber beklagen, dass ich nicht besser esse.
John
quelle
9

Du musst nichts sagen. Die Tatsache, dass die Entwickler geantwortet haben, ist ein Hinweis darauf, dass sie bereits wissen, dass das Problem besteht, und dass dies (zumindest einigen) Benutzern Schmerzen bereitet.

Letztendlich wird nichts, was Sie sagen, den Entwickler davon überzeugen, für Sie zu arbeiten, wenn er dies nicht möchte.

Dean Harding
quelle
9

Ein gutes Open-Source-Projekt verfügt über ein System zur Anforderung von Fehlern / Features, in dem Benutzer Fehler / Features einreichen und andere über sie abstimmen können, damit die Betreuer erkennen können, was für die Community insgesamt wichtig ist. Der schnellste Weg, um Ihre Funktion zu implementieren, besteht darin, einen Patch dafür einzureichen. Periode ... daran führt kein Weg vorbei.

Michael Brown
quelle
8

Persönlich würde ich eher die Antwort "Dies ist ein bekanntes Problem, aber es ist leider kein Problem, das in Kürze behoben wird. Entwickler arbeiten an anderen Problemen. Derzeit gibt es keine ETA."

Die Antwort "Patch einreichen" ist sehr unhöflich, da sie eine Reihe von Dingen voraussetzt:

  1. Alle Benutzer des Programms sind Programmierer, oder alle Programmierer sind Programmierer.
  2. Alle Programmierer kennen die Sprache, in der sich das Programm befindet.
  3. Alle Programmierer kennen alle Probleme, die ein Programm haben könnte.
  4. Alle Programmierer haben freie Zeit, um an einem Open-Source-Projekt zu arbeiten.

Selbst wenn wir davon ausgehen, dass der "Submit a Patch" -Antwortgeber all das oben Genannte weiß, klingt die Aussage einfach so, dass "X Stunden meiner Zeit mehr wert sind als die Größenordnungen mehr Stunden Ihrer Zeit, die Sie aufstehen möchten das Problem zu beschleunigen und zu beheben ".

Wenn ich von einem Entwickler eine unhöfliche Antwort bekomme, wenn ich nach einem Problem frage oder einen Fehler einreiche, stoppe ich im Allgemeinen die Verwendung dieses Programms. Ich benutze uTorrent nicht mehr (nicht Open Source, aber der Punkt bleibt), zum Beispiel, weil die Antworten, die ich in ihrem "Support" -Forum erhielt, so unhöflich waren. Ich habe ein Problem im Bug Reports-Forum gemeldet. Der Thread wurde sofort mit einem Link zu einem anderen Thread gesperrt, der sich auf ein ähnliches, aber anderes Thema in einem Thread bezog (der natürlich auch gesperrt war). In der Zwischenzeit habe ich im allgemeinen Diskussionsforum einen Thread geöffnet, in dem gefragt wurde, ob jemand eine Problemumgehung gefunden hat. In der Zeit, die es dauerte, um diesen Thread zu speichern und zu überprüfen, ob mein erster Thread gesperrt war, war mein Thread im Allgemeinen gesperrt und mein Forum-Account wegen störenden Verhaltens gesperrt. Ich habe uTorrent deinstalliert und bin seitdem nicht mehr zurück.

Bacon Bits
quelle
Meinen Sie "Ich möchte lieber eine Antwort von" als "Ich möchte lieber keine Antwort von"?
Andrew Grimm
Vielen Dank insbesondere für den ersten Absatz. Es ist erstaunlich, wie fremd solch eine grundlegende Form der beruflichen Höflichkeit für so viele Menschen sein kann. Unabhängig davon, ob Sie bezahlt werden oder nicht, müssen Sie das Problem bestätigen und seinen Status erläutern (auch wenn der Status "zurückgestellt" ist).
Aaronaught
8

Das bloße Antworten auf "Submit a Patch" ist unhöflich, aber dennoch ... Wenn Sie Open-Source-Software für irgendetwas Ernstes verwenden, müssen Sie bereit sein, sich darum zu kümmern, falls dies erforderlich sein sollte.

Das Folgende basiert auf einem Beitrag von Jeremias Maerki (von Apache FOP):

Wenn etwas bei Ihnen nicht funktioniert, haben Sie mehrere Möglichkeiten:

  • Dies ist Open Source: Sie können es selbst beheben.
  • Wenn Sie das Problem nicht selbst beheben können, können Sie warten, bis jemand Zeit zur freien Verfügung hat und der Meinung ist, dass die Implementierung Spaß macht.
  • Wenn dies nicht der Fall ist, können Sie jemanden finden oder einstellen, der dies für Sie erledigt.

Ich denke, es ist eine sehr gültige Vollversion der "Submit a Patch" -Antwort.

Bertrand Delacretaz
quelle
6

Jedes Mal, wenn ich das sehe, suche ich sofort nach einem alternativen Produkt. Für mich ist dies ein gefährliches Zeichen dafür, dass sich die Betreuer entweder nicht um ihre Benutzer kümmern (schlecht, wenn Ihr Projekt überall verwendet wird) oder das Interesse an dem Projekt verloren haben. Beides bedeutet normalerweise, dass das Projekt bald ausfällt oder von einer Stagnation geplagt wird, da die Entwickler sich weigern, das Projekt voranzutreiben

(Beachten Sie, dass ich nicht sage, dass der allererste Fehlerbericht, den Sie sehen, mit dieser Art von Antwort ausgeführt wird. Sie müssen sich einen allgemeinen Trend ansehen. Wenn die meisten Fehlerberichte mit dieser Art von Antwort enden, befolgen Sie diesen Rat. Wenn Es sind nur ein paar, dann handelt es sich höchstwahrscheinlich um Feature-Anfragen, die nicht den Projektzielen entsprechen oder extrem anwendungsspezifisch sind.

Wie @MainMa sagte, ist es sehr schwierig, einen Beitrag zu einem brandneuen Projekt zu leisten. Die meisten Entwickler verstehen das nicht, da sie seit Monaten / Jahren an dem Projekt arbeiten und es für sie sinnvoll ist. Dies kann manchmal ein ehrlicher Fehler sein.

TheLQ
quelle
3

Ich scherze gelegentlich, dass freie Software frei sein kann wie in Bier, frei wie in Sprache oder frei wie Sie bekommen, wofür Sie bezahlen.

Ich sage es zwar im Scherz (ich arbeite für ein Unternehmen, das viel OSS einsetzt), aber ich denke, dass es eine Wahrheit gibt - wenn Sie kommerziellen Support wünschen, müssen Sie entweder kommerzielle Software mit einem geeigneten Support-Angebot verwenden oder einen finden Open-Source-Softwarelösung, mit der Sie diesen Grad an Unterstützung erhalten (in der Regel durch eine Person, die dafür bezahlt wird, möglicherweise jedoch durch Ihr Unternehmen, das Entwicklungsressourcen für die Bearbeitung einsetzt oder zuweist).

"Einen Patch einreichen" ist ärgerlich, aber es hebt etwas über OSS hervor und sollte vielleicht daran erinnern, dass OSS nicht in jeder Situation für jeden geeignet ist, zumindest nicht, ohne sicherzustellen, dass Sie ein solides Support-Framework dafür haben (auch nicht) Inhouse, bezahlt für oder durch die Community).

Wir denken oft an Software, die kostenlos ist wie in Bier, aber nicht wie in Sprache (das ist nicht offene Freeware). Vielleicht ist dies ein Fall, in dem wir über die Software so frei wie in der Rede, aber nicht wie in Bier nachdenken sollten .

Jon Hopkins
quelle
2

Wechseln Sie zu einer gut gewarteten Alternative.

Aus meiner Erfahrung mit gut gepflegten Open-Source-Projekten geht hervor, dass wenn Sie einen gut definierten Fehlerbericht oder eine Feature-Anfrage erstellen, die Wahrscheinlichkeit sehr hoch ist, dass diese implementiert werden.

vartec
quelle
2
Fehlerberichte und Featureanfragen sind häufig nicht genau definiert. Meine Erfahrung ist, dass Kompetenz und Respekt gut funktionieren. Auch eine genau definierte Merkmalsanforderung wird bestenfalls berücksichtigt. Dies kann als niedrig eingestuft werden, oder es kann etwas sein, was die Projektgruppe explizit nicht tun möchte (es gibt gute Beispiele in den PuTTY-FAQ und eine schöne Liste von Funktionsanforderungen, die nach Kategorien gruppiert sind).
David Thornley
1

"Ich kann immer nur an einer Sache arbeiten, aber ich kann mich über viele Dinge gleichzeitig beschweren. Ich denke, beide Funktionen sind nützlich." - akkartik auf ycombinator .

Vincent Scheib
quelle
1

Ich denke, wenn man an einem Projekt arbeitet und Releases und Support anbietet, entsteht ein unausgesprochener, impliziter Supportvertrag zwischen Entwickler und Benutzer. Der Entwickler hat die implizite Verantwortung übernommen, die Codebasis für seine Benutzer zu unterstützen, einschließlich des Hinzufügens von Funktionen auf Anfrage.

"Einen Patch einreichen" bedeutet meiner Meinung nach im Grunde genommen, den Benutzern den Finger zu geben. Dies ist kontextabhängig - manchmal ist die Implementierung zu aufwendig, manchmal würde das vorhandene Projekt zerstört oder es kommt zu einer schwachen Kreaturitis oder einer Reihe anderer Gründe. Aber letztendlich heißt es: "Scheiß auf dich, tu es nicht". In meinen Augen ist dies in gewisser Weise ein Verstoß gegen diesen unausgesprochenen Vertrag.

Paul Nathan
quelle
Es ist kein Vertrag, es sei denn, beide Seiten erhalten etwas. Was das Projekt normalerweise will, sind gut gemachte Fehlerberichte und häufig gut gemachte Feature-Anfragen, und nicht alle, die eingehen, werden dem Ende des impliziten Vertrags gerecht.
David Thornley
1
@Aaronaught: Sie bieten nur dann kostenlose Tests an, wenn sie Fehlerberichte einreichen, die detailliert genug sind, um damit zu arbeiten. Ich habe meinen Anteil an Fehlermeldungen gesehen. Sie können oder können nicht gute Werbung zur Verfügung stellen. Die meisten Leute, die F / OSS verwenden, geben nichts Nützliches zurück, was in Ordnung ist, aber es ist sicher nicht eine Seite eines Vertrages.
David Thornley
1
@ David: Würden Sie bitte aufhören zu versuchen, die Konversation nur auf die schwierigsten / unproduktivsten Benutzer zu beschränken? Wenn wir verallgemeinern wollen, muss diese Verallgemeinerung für die gesamte Benutzer- und Mitwirkendenbasis als Kollektiv gelten. Veröffentlichung bringt euch alle diese Leute. Als Gegenleistung für das Gute, das Sie von vielen bekommen, bekommen Sie einige Probleme von vielen anderen. So ist das Leben.
Aaronaught
1
@Aaronaught: Wenn wir verallgemeinern wollen, müssen wir sicherstellen, dass wir angemessen verallgemeinern. Ich versuche nicht, die Konversation auf die schlechtesten Benutzer zu beschränken, sondern nur darauf hinzuweisen, dass sie da sind. Ein Großteil der Konversation scheint davon auszugehen, dass alle Benutzer in gewisser Weise Mitwirkende sind, und das ist schlichtweg nicht wahr. Wenn wir nur über die Benutzer sprechen, die für das Projekt nützlich sind, erscheint es fair, nur über die Mitglieder des Projektteams zu sprechen, die im Allgemeinen höflich sind.
David Thornley
2
@ David: Natürlich gibt es einige Benutzer und externe Mitarbeiter, die helfen, und auch einige, die Probleme verursachen. Offensichtlich gibt es einige Entwickler, die höflich und professionell sind, soweit es gesunder Menschenverstand und gute Zeitmanagementfähigkeiten erlauben, und es gibt auch Entwickler, die unhöflich und unprofessionell sind. Dies war eine Frage zum Umgang mit der letzteren Gruppe von Entwicklern. Die Existenz von "Problemnutzern" ist unbestritten, aber es ist ein roter Hering, der nichts anderes dient, als die Diskussion zu entgleisen, indem er eine kontroverse Situation schafft - lassen wir es also in Ruhe.
Aaronaught
1

Es gibt verschiedene Möglichkeiten, dies zu tun.

  • Feature-Vorschlag und Abstimmung. aber das braucht Zeit.

  • Lassen Sie sich von einer Firma einstellen, die das Patch benötigt. Dies ist natürlich die beste Lösung, aber machen Sie sich bereit, mit demjenigen zusammenzuarbeiten, der die Open Source-Software herstellt, die Sie aktualisieren möchten.

  • Es ist auch wichtig herauszufinden, warum die Funktion überhaupt nicht implementiert ist. Oft ist die Funktion nicht in der Linie des Softwareprojekts: Das Team möchte diese Funktion nicht, fühlt sich nicht notwendig oder denkt nur, dass dies nicht der richtige Weg ist, etwas zu tun. In diesem Fall sollten Sie das Projekt einfach teilen und selbst erstellen.

  • Verwenden Sie proprietäre Software, die genau das tut, was Sie wollen.

  • Denken Sie daran, dass OOP-Software die Integration eines Features häufig vereinfacht.

  • Jammern auf einer Mailingliste, im Internet oder in einem Forum wird nur Programmierer verärgern und OSS-Befürwortern Munition geben.

jokoon
quelle
0

Sie können nichts sagen, was ihn dazu bringt , es zu tun. Warum sollte er schließlich? Aufgrund der Wünsche eines Benutzers? Es ist nicht gut genug, ein Grund.

Aber wenn Sie eine vernünftige Anzahl von Benutzern sammeln und vernünftige Gründe angeben können ("Ich will es" ist kein vernünftiger Grund), warum diese Funktion im Allgemeinen nützlich sein könnte, und für Sie und die Anzahl anderer könnte er einfach seine Meinung ändern .

Es gibt jedoch auch einen Sonderfall, der berücksichtigt werden muss. Das ist ein Entwickler. Es ist ihm leid, die App zu entwickeln, und er möchte sie langsam verlassen (es gibt noch andere Dinge zu tun). Daher setzt er Feature-Anforderungen langsam außer Kraft. Abgesehen davon, dass er versucht, ihn davon zu überzeugen, den Code freizugeben, gibt es in diesem Fall praktisch nichts, was Sie tun können, selbst in Bezug auf das oben Gesagte.

Turm
quelle
Alternativ hat der Entwickler genügend Feature-Anfragen, um ihn für den Rest des Jahrhunderts zu beschäftigen. Er würde gerne Ihre aufnehmen, sieht jedoch nicht vor, dass er bald darauf zugreifen kann.
David Thornley
@ David Thornley - Das auch.
Turm
0

Insbesondere Open-Source-Projekte sind für die Entwicklung eines bestimmten Features oder für die Finanzierung derselben freundlich, auch wenn das neue Feature es nicht bis zu den offiziellen Releases schafft.

Ja, eine der Ideen, die hinter dem Veröffentlichen von Open Source stehen, ist, dass jeder und jede das Recht und die Verantwortung hat, seine eigenen Beiträge zu leisten.

Bei geschlossenen Quellen besteht Ihre beste Ressource darin, eine statistisch wichtige Gruppe aus der Benutzerbasis zusammenzustellen, die nach Lösungen sucht, die Ihren Vorstellungen entsprechen.

Apalala
quelle
2
Das Recht , Beiträge zu leisten, ja, aber als ich das letzte Mal die GPL gelesen habe, wurde nichts über die Verantwortung der Endnutzer erwähnt, ihre eigenen Beiträge zu leisten. Das ist ein bisschen weit hergeholt, findest du nicht?
Aaronaught
0

Nach meiner Erfahrung wird diese Antwort normalerweise gegeben, wenn die Benutzeranforderung nicht zum Projektziel passt. Es passiert, wenn die Leute denken, dass Sie alles umsetzen werden, was sie Ihnen vorschlagen, und ein bisschen mehr - kostenlos, Open Source und eine großartige und glückliche Zukunft.

Das Einreichen eines Patches ist eine relativ unhöfliche Antwort (und sollte natürlich vermieden werden. Besonders in dieser präzisen und scharfen Form. Es gibt viele Möglichkeiten, ungefähr die gleiche Nachricht auszudrücken - zum Beispiel, die Benutzer zu Hilfe einzuladen, weil Sie helfen Ich habe keine Zeit, es selbst zu implementieren. Aber so wie es ist, ist es ein klarer Indikator dafür, dass ich keine Zeit verschwenden muss. Daher kann man nicht viel dagegen tun, und es gibt auch keine „kanonische“ Reaktion.

Die beste Antwort, die ich mir vorstellen kann, ist, tatsächlich einen Patch zu präsentieren . Angenommen, Ihr Patch funktioniert, haben Sie zumindest bewiesen, dass die Idee nicht völlig unrealistisch ist. In der Regel bedeutet dies, dass die für das Projekt Verantwortlichen den Vorschlag erneut prüfen.

Alexander Gessler
quelle
1
Ich denke nicht, dass ein Entwickler "einen Patch einreichen" bezüglich einer Anfrage, die nicht zum Ziel des Projekts passt, antworten sollte. Das ist mehr unehrlich als unhöflich. Entweder wird die Software aufgebläht und der Entwickler hasst Sie dafür, oder er akzeptiert den Patch nicht und verschwendet effektiv Ihre Zeit. Letzteres ist wahrscheinlicher. Der Entwickler sollte wirklich ehrlich sagen "Wir wollen das nicht ändern, weil ..." und damit fertig sein.
Rei Miyasaka
@Rei Miyasaka: Persönlich wäre ich wütend, wenn ich "einen Patch einreichen" würde, die Arbeit zur Erstellung eines qualitativ hochwertigen Patches erledigen und dann erfahren würde, dass sie das Feature sowieso nicht wollen.
David Thornley
@ David Ja, wie? Ich würde ein oder zwei Stühle werfen.
Rei Miyasaka
0

"Submit a Patch" ist eine legitime Lösung für Ideen, die nicht in die Ziele des Projekts passen. Auf lange Sicht ist es wahrscheinlich besser, Ihnen zu sagen, dass die Idee scheiße ist, oder dass Sie versuchen, das Projekt für etwas zu verwenden, das weit über den beabsichtigten Umfang hinausgeht. t Sie versuchen, es in unsere vorhandene Codebasis einzupassen "ist manchmal angemessen.

Wenn es geringfügig ist und für die beabsichtigten Benutzer des Projekts wirklich von Nutzen ist, reichen Sie einfach den Fehlerbericht ein, beschreiben Sie das Problem klar, geben Sie Schritte zur Reproduktion an, geben Sie an, dass Sie den aktuellen nächtlichen Build verwenden, und belassen Sie ihn dabei.

Was wie eine kleine einfache Änderung scheint, die Tonnen von Benutzern helfen würde, kann tatsächlich ein großer Schmerz im Arsch sein, den niemand außer Ihnen verwenden würde. Das ist der beste Fall für "Submit a Patch".

Es ist auch möglich, dass Sie auf einen Fall wie den notorischen Glibc-Betreuer gestoßen sind, der den Eindruck zu haben scheint, sein System sei das Universum, seine Interpretation von Spezifikationen sei das Wort Gottes, und das ist alles, was es dafür gibt von wievielen Leuten würde es anders bevorzugen.

Kevin Peterson
quelle
Ich glaube nicht, dass sich jemand dafür entscheiden würde, diese Frage zu stellen, wenn er wüsste, dass die Veränderung ein großer Schmerz im Arsch sein würde, der nur von einer Person benutzt wird. Warum also nicht höflich und kurz erklären, warum es so eine große Sache ist und nicht sofort erledigt werden kann, anstatt "einen Patch einzureichen"?
Mr. Shickadance
2
"Submit a Patch" macht einen wirklich miesen Brushoff, da es möglich ist, dass jemand einen Patch einreicht. Es sollte für Nizza-to-Haves mit niedriger Priorität reserviert werden.
David Thornley
0

Ich würde vorschlagen, ein Projekt für die Implementierung der Funktion auf Websites wie RentACoder / ELance / etc zu erstellen und darüber im Forum des ursprünglichen Open Source-Projekts zu posten. Alle Programmierer der Open Source-Projekte, einschließlich des Autors, haben jetzt einen finanziellen Anreiz, Ihre Anfrage zu prüfen.

Renji Panicker
quelle
-1

Ich habe mich angemeldet, um diese Frage zu beantworten.

Ist eine Retorte erforderlich? Diese Antwort wird normalerweise verwendet, wenn der Entwickler das Problem kennt, es aber nicht für wichtig hält.

Ich werde Ihnen ein lebendes Beispiel geben. ubuntu hat die Systray-Unterstützung eingestellt (kann aber durch das Auflisten einer App umgangen werden) und neue App-Indikatoren hinzugefügt. Einige Apps wie Jupiter verließen sich auf Systray-Unterstützung, sodass der Entwickler über die Arbeit berichtete. Statt Unterstützung für App-Indikatoren hinzuzufügen, bat ich den Entwickler, die App-Indikator-Unterstützung hinzuzufügen. Die Antwort lautete "Senden Sie uns Patches". auf die Frage, warum sie sich entschieden haben, dies nicht umzusetzen. da war das

Ich habe kein Interesse daran, meine Zeit damit zu verbringen, Unterstützung für eine Bibliothek aufzubauen, die ich niemals nutzen werde, nur weil es jemand mit viel Geld verlangt, indem er die Fähigkeit meiner Anwendungen, auf seiner Linux-Distribution ordnungsgemäß zu funktionieren, auf eine schwarze Liste setzt, nur weil er es kann.

Wenn es ein echtes technisches Problem wäre, würde ich wahrscheinlich Maßnahmen ergreifen, aber dies ist nur ein politisches Manöver, also nein, ich glaube nicht.

Nein, ich werde es nur auf die Whitelist setzen

Fair genug. Der Entwickler hat Grund, ein Feature nicht zu implementieren, ist aber bereit, Patches zu akzeptieren. Dies ist nicht wirklich unhöflich und beleidigend, so dass es keiner Retorte bedurfte.

Fazit: Die kanonische Retorte besteht darin, den Patch einzureichen. Wenn dies nicht möglich ist, ist keine Retorte erforderlich

Lincity
quelle
-1

Starten Sie ein Kopfgeld für die gewünschte Funktion.

Oder kaufen Sie das Produkt, das behauptet, genau das zu tun, was Sie wollen, und missbrauchen Sie das Support-Personal, wenn Sie feststellen, dass das Marketing nicht Ihren Erwartungen entspricht.

CyberFonic
quelle
-2

Das Beste, was mir einfällt, ist "du saugst".

Tut mir leid, das ist offensichtlich nicht sehr hilfreich, aber ich denke, dies ist nur eine der unglücklichen Situationen, in denen der Benutzer komplett durchgeknallt ist. Ein brutal ehrlicher Appell an das Gewissen des Entwicklers ist eine letzte Anstrengung.

Sie könnten versuchen, "Spenden" anzubieten ( Husten ), um Ihr Problem anzugehen, aber ich befürchte, dass eine solche Praxis, wenn sie verbreitet wird, zu einem wirklich schlimmen Integritätsverlust in der Branche führen würde, da Bugfixes niemals rentabel gemacht werden sollten, auch nicht für "Freie" oder kommerzielle Software.

Rei Miyasaka
quelle