Wie sagt man "es ist Open Source, reiche einen Patch ein", damit es freundlich ist?

In den Antworten von Was ist die kanonische Antwort auf "Es ist Open Source, reichen Sie einen Patch ein"? Viele Leute äußerten die Meinung, dass es arrogant und unhöflich sei, nur die Leute zu bitten, einen Patch einzureichen.

Mir scheint jedoch, dass Sie als Entwickler eines Open-Source-Projekts auf der Mailingliste viel mehr Funktionsanfragen sehen, als Sie möglicherweise implementieren könnten. Wenn ein Benutzer also sagt: "Ich möchte Feature X sehen", ist die Wahrheit in der Regel, dass die Chancen, dass es implementiert wird, sehr gering sind, es sei denn, sie reichen selbst einen Patch ein. Manchmal reicht auch eine kleine Ermutigung aus, um einen Benutzer in einen Mitwirkenden zu verwandeln.

Auf der anderen Seite möchten Sie keine (potenziellen) Mitwirkenden abschrecken, indem Sie als unhöflich abschneiden.

Wie würden Sie "Bitte senden Sie Patches, anstatt nach Funktionen zu fragen" auf freundliche Weise sagen?

Update: Danke für alle Vorschläge! Ich sehe, dass die meisten von ihnen ziemlich lange Erklärungen erfordern. Aber da ich lieber vermeiden möchte, entweder (a) jeden zweiten Tag dasselbe zu erklären (es dauert einfach zu lange) oder (b) Ausschnitte zu verwenden, die ich in E-Mails einfüge (es wird sehr schnell unpersönlich), frage ich mich: Hat hat jemand dies in einem Dokument geschrieben, auf das ich verlinken kann?

(Projektspezifische Dinge wie das Schreiben von Tests, das Kompilieren des Codes und das Einreichen des Patches müssen natürlich noch dokumentiert werden, aber ich denke, diese technischen Probleme sollten trotzdem in die Datei CONTRIBUTING.txt aufgenommen werden.)

Das tust du nicht.

Soweit ich es erlebt habe, sind die Beitrittskandidaten Bastler und reichen keine Feature-Anfrage ein, indem sie sie lediglich anfordern. Sie fordern dies normalerweise bereits mit einer gewissen Beteiligung an:

• Wäre es nicht süß, wenn [...]? Es könnte möglich sein, A, B und C zu machen. (Das ist ein Köder für: Ich habe keine Zeit, aber hier ist eine spezielle Idee, falls Sie es tun.)
• Hier ist ein Patch zu tun / hier ist ein Fix für [...].
• Ich überlege, einen Patch zu schreiben, um [...] etwas zu tun, und könnte Feedback verwenden / ist jemand daran interessiert, mitzuhelfen.
• Etc.

Codierer, die eine Funktionsanforderung direkt einreichen, tun dies in der Regel aus einem bestimmten Grund. Einige davon beinhalten (und ich weiß, dass die letzten beiden zum Beispiel in WordPress vorkommen):

• Sie sind tief in anderen Open Source Projekten verwurzelt, haben also keine Zeit.
• Sie sind Trittbrettfahrer und beabsichtigen, die Dinge so zu halten.
• Es geht weit über ihre Fähigkeiten hinaus und ist in einer Sprache geschrieben, über die sie nichts wissen.
• Sie nutzen die Software aus Mangel an einer besseren Option und wollen sich nicht mit einem stinkenden Haufen Batsh * t ^ \ b-Code befassen.
• Sie können nicht länger belästigt werden, weil ihre vorherigen Patches ignoriert / verworfen wurden, dh sie denken, sie würden ihre Zeit verschwenden.

Noch typischer ist, dass Feature-Anfragen von Endbenutzern eingehen, die den Patch selbst dann nicht zur Verfügung stellen konnten, wenn sie dies wollten. Vor allem, wenn Sie außerhalb des Ticketsystems eingereicht werden.

Ich denke, Ihre wichtigste Priorität sollte es sein, potenzielle / bestehende Mitarbeiter nicht zu vertreiben, sondern zu versuchen, aktiv neue zu gewinnen. Es ist enorm wichtig, und ich sage dies aus Erfahrung. Ich habe einen seltsamen Weg gefunden, eine neue Codebasis zu finden. Dazu gehört das flüchtige Lesen des Codes, um ein gewisses Verständnis dafür zu erlangen, das Einsteigen in das Ticketing-System und das Beheben von leicht aussehenden Fehlern, um die Interna gründlich zu lernen (und zu archivieren) neue wie ich teste). Im Laufe der Jahre habe ich einige Projekte mit Dutzenden von Tickets und Patches überflutet. Oftmals werden diese Tickets nicht rechtzeitig beachtet (nicht einmal eine Bestätigung, z. B. Weiter so!) - auch wenn dokumentierte Diagnoseschritte und Komponententests beigefügt sind.

Kurz gesagt, Sie erklären, dass Sie nicht unbegrenzt Zeit haben, um ihre Arbeit kostenlos zu erledigen. (Sie können das "Gratis" -Bit überspringen), und dass sie jederzeit beitragen können, es ist nicht "Ihr" Projekt, es ist jedermanns Projekt.

Sie sagen also: "Es tut uns wirklich leid, das ist eine großartige Idee, aber wir sind einfach zu beschäftigt mit all den anderen laufenden Arbeiten. Wir werden sie der Liste hinzufügen, aber wenn Sie dies wirklich wollen, und Sie möchten uns helfen, indem Sie zu dem Projekt beitragen, dann wäre das wunderbar. Wir haben einige Unterlagen, die den Jungs helfen, Änderungen am Projekt vorzunehmen, sie sind hier, wenn Sie also die Fähigkeiten und die Zeit haben Wenn Sie uns helfen möchten, senden Sie uns bitte einen Patch mit Ihren Änderungen. Möglicherweise müssen wir einige Modifikationen daran vornehmen, damit er den Projektstandards entspricht große Gunst, indem wir uns zumindest für diese Arbeit stark machen und wir lieben dich, weil du uns geholfen hast ".

Wenn Sie einmal nach Patches gefragt haben, können Sie diese natürlich niemals zu lange auf Ihrem Ticketsystem belassen. Wenn Sie zu viel davon bekommen, werden Sie sie mehr integrieren, als Sie es bisher getan haben. Das mag Ihnen vielleicht nicht gefallen, aber es ist notwendig, wenn Sie möchten, dass Patches weiterhin verfügbar sind.

Bleiben Sie höflich und erklären Sie die Situation klar. Was ist mit so etwas wie:

Danke für deine Rückmeldung. Wir finden Ihr Feature sehr interessant, aber trotz unserer Bemühungen, die am häufigsten angeforderten Features in unserem Produkt zu implementieren, haben wir nicht genügend Zeit, um sie alle zu implementieren. Wenn Sie ein Entwickler sind, können Sie sich uns anschließen, indem Sie einen Beitrag zum Projekt leisten, da es Open Source ist.

Sehen Sie, Sie können nicht einfach sagen: "Warum belästigen Sie mich mit Ihren Anfragen? Ich bin nicht hier, um kostenlos für Sie zu arbeiten. Wenn Sie diese Funktion wünschen, können Sie sie selbst implementieren." Die Person ist möglicherweise kein Entwickler, kennt möglicherweise nicht die für die Entwicklung des Produkts verwendete Sprache usw.

Anstatt unhöflich zu sein, können Sie vorschlagen , an dem Projekt teilzunehmen, und auch erklären, warum Sie die Funktion möglicherweise nicht selbst implementieren können.

Eine andere Möglichkeit, nicht unhöflich zu sein, besteht darin, nichts sagen zu müssen. Wenn Sie eine Website haben, auf der die Benutzer Ihrer Anwendung möglicherweise neue Funktionen vorschlagen und Fehler melden, möchten Sie die Elemente möglicherweise nach ihrer Priorität sortieren: Wenn beispielsweise eine Funktion von 10 000 Benutzern angefordert wird und eine andere von nur 10 Benutzern Es besteht die Möglichkeit, dass der erste zuerst implementiert wird.

Auf einer solchen Website können Sie immer einen "Implementiere es selbst" -Vorschlag für die Funktionen platzieren, die nach einigen Tagen oder Wochen nicht genügend positive Bewertungen von anderen Benutzern erhalten haben.

Vielen Dank für die Anfrage. Wir haben es zu unserem Projekt-Backlog hinzugefügt und werden es in Kürze überprüfen.

Bitte beachten Sie, dass wir aufgrund des Umfangs der Anfragen nicht garantieren können, dass alle implementiert werden. Wir sind auf ehrenamtliche Mitarbeiter angewiesen. Wenn Sie also Entwickler sind, sollten Sie einen Teil Ihrer Zeit spenden und einen Patch einreichen . Ansonsten wissen Sie bitte, dass wir alle hart daran arbeiten, den Rückstand zu überwinden, und werden Ihre Anfrage so schnell wie möglich bearbeiten.

War das wirklich so schwer?

Anstatt nur "Patch einreichen" zu sagen, sollten Sie etwas mehr ausführen.

• Stellen Sie klar, dass Sie momentan oder in absehbarer Zeit keine Zeit dafür haben. Wenn andere also eine baldige Implementierung wünschen, gibt es keine andere Möglichkeit, als einen Patch bereitzustellen.
• Nehmen Sie sich Zeit, um die Funktion zu bewerten. Wenn Sie es aufrichtig mögen, ist es kein Schaden, das zu sagen. Menschen ermutigen. Oder wenn Sie der Meinung sind, dass die Funktion tatsächlich schlecht ist, nehmen Sie sich die Zeit, dies zu erklären.
• Stellen Sie eine Starthilfe bereit. Niemand kennt die Codebasis so gut wie Sie. Sie haben nicht die Zeit, es zu tun, aber Sie wissen wahrscheinlich genau, wie Sie es tun würden und wo Sie anfangen würden. Innerhalb von 5-10 Minuten können Sie das Wissen weitergeben, dass andere Stunden benötigen würden, um dies herauszufinden. Auch dies hilft Ihrem Gesamtbild, sich durchzusetzen. Anstatt fremde Features in Ihr Projekt einbinden zu lassen, können Sie Mitwirkende zu einer netten Ganzzahl führen.

Folgendes sage ich normalerweise ...

"Das ist ein interessanter Vorschlag und es wäre cool, wenn FooBarLib das könnte. Leider ist FooBarLib nur ein Freizeitprojekt für mich, so dass es unwahrscheinlich ist, dass ich in naher Zukunft dazu komme. Ich begrüße es, wenn ich bei FooBarLib einreiche, Wenn Sie dies also selbst implementieren können, können Sie einen Patch einreichen (lesen Sie zuerst unsere "Wie Sie zu FooBarLib beitragen" -Richtlinien).

Zusätzlich zu den netten Möglichkeiten, "Patch einreichen" zu sagen, bieten Sie auch eine entwicklerorientierte Dokumentation, damit andere, die das Feature wirklich wollen, auf einfache Weise mit Ihrem Projekt Schritt halten können. Viele Projekte sind nicht entwicklerfreundlich und erfordern Tage, um Tausende von Codezeilen und Tonnen von kleinen Testfällen zu lesen, die in verschiedenen Teilen des Systems stöbern, um die richtigen Ergebnisse zu erzielen.

Wenn Sie den möglichen Entwicklern helfen, sind sie mehr als bereit, Hilfe zu leisten. Dies bedeutet eine gute Codedokumentation, gute Wiki-Seiten, die den Ablauf erklären (oder ein gutes UML / Whiteboard-Diagramm), und eine einfache Möglichkeit, Patches zu akzeptieren.

Ich mag die Art und Weise, wie Github andere dazu ermutigt, das Projekt zu forken. Unter verschiedenen Benutzerkonten können mehrere Versionen desselben Projekts vorhanden sein. Wenn Ihnen die Richtung, in die ich das Projekt verwende, nicht gefällt, geben Sie sie bitte auf. Sie können ganz einfach Pull-Requests einreichen, müssen aber nicht darauf warten, dass ich sie akzeptiere.

Meine Antwort lautet also oft, gib es einfach.