Wie sollten Beiträge zu einem Open Source-Projekt von den Eigentümern verwaltet werden?

Wie würde man beim Verwalten eines Open Source-Projekts (mit einem Dienst wie GitHub) auf Folgendes reagieren:

Jemand hat freundlicherweise einen Patch eingereicht, um eine neue Funktion hinzuzufügen oder ein Problem zu beheben. Eine der folgenden Situationen tritt auf:

Der Quellcode entspricht nicht einer oder mehreren Namenskonventionen usw.
Ich bin der Meinung, dass der Quellcode in gewisser Weise verbessert werden könnte. Vielleicht kann derselbe Effekt mit einer viel einfacheren Quelle erzielt werden, oder vielleicht wäre ein anderes nützliches Merkmal erforderlich.

Q1. Kann ich die eingereichte Quelle ändern? (ist das bei GitHub möglich?)

Q2. Sollten alle derartigen Einreichungen gemäß den Einreichungsrichtlinien abgelehnt werden?

Q3. Wenn ja, was ist mit einer wirklich guten Idee, die schlecht umgesetzt wurde? Ist es für mich akzeptabel, einfach fortzufahren und meine eigene zu erschaffen?

Ich möchte meinen Beitrag fördern, aber gleichzeitig ist es wichtig, einen bestimmten Standard beizubehalten.

open-source github

— Lea Hayes
quelle

Antworten:

Richten Sie, falls noch nicht geschehen, ein Dokument ein, in dem die Projektstandards beschrieben werden. Achten Sie darauf, alles zu skizzieren Sie Sie für wichtig halten, wenn Sie Code in Ihr Projekt einbringen.

Antworten Sie dann auf die Person, die den Code bereitgestellt hat, und geben Sie an, dass Sie den Beitrag sehr schätzen und dass Sie den Patch einschließen möchten, aber es gibt einige Probleme. Stellen Sie einen Link zum Dokument bereit und zitieren Sie die speziellen Probleme, die Sie sehen. Bitten Sie diese Person dann, die Probleme zu beheben und den Code erneut zu übermitteln.

— Jeremy Heiler
quelle

Ich denke, der Linux-Kernel hat eine Art Bereich "Änderungen, die Verbesserungen erfordern" für dieses Szenario.

— seppo0010

Auf lange Sicht wird es dem Projekt und der Community insgesamt zugute kommen, wenn Sie die Leute dazu bringen, ihre eigenen Beiträge zu verbessern. Es ist jedoch absolut in Ordnung, die Funktion selbst erneut zu implementieren, vorausgesetzt, Sie sind höflich.

— David Schwartz

Ich habe eine ganze Reihe von Projekten gesehen, die einige dieser Dinge automatisieren, wenn Sie nach einem Pull fragen.

— Andrew T Finnell

Nur ein Hinweis für Benutzer von GitHub: Wenn Sie das oben genannte Dokument benennen CONTRIBUTING, wird beim Senden einer Pull-Anfrage ein Link zu diesem Dokument angezeigt. Es kann helfen, Zeit im Voraus zu sparen, wenn die Benutzer häufig auftretende Probleme zuerst selbst lösen können.

— Michael Mior

Wenn es nicht zu viele Mitwirkende gibt und dieser Beitrag ziemlich wertvoll ist, können Sie den Patch so wie er ist akzeptieren und dann beim nächsten Festschreiben Teile davon selbst neu schreiben oder ihn neu formatieren, um die Codierungsstandards zu bestätigen. - Anschließend senden Sie eine E-Mail mit einem Link zu den Änderungen, die Sie vorgenommen haben. Hoffentlich wird der Mitwirkende dann das Diff untersuchen und beim nächsten Mal einen besseren Patch einreichen, den Sie nicht ändern müssen.

Dies ist möglicherweise eine gute Idee, wenn Sie noch keine Contributors Guide- oder Coding Style- Dokumente verfasst haben. Tatsächlich können Sie auf diese Weise fortfahren (Patches akzeptieren und ändern, Links zu anderen Versionen per E-Mail senden), bis Sie bemerkt haben, welche Fehler die meisten Autoren machen. Und dann nehmen Sie nur diese Fehler in einen Leitfaden für Mitwirkende auf und einen Styling-Leitfaden ein .

Wenn Sie die Dinge auf diese Weise tun, lauten die Antworten auf Q1-Q3:

F1: Ja, bearbeiten Sie die Übermittlung in einem nachfolgenden Commit
F2: Nicht zutreffend (ich gehe davon aus, dass Sie noch keine Richtlinien geschrieben haben)
F3: Sag Danke und schreibe es um :-) (Vielleicht ist es sinnlos, einen Patch überhaupt anzuwenden, wenn du ihn beim nächsten Commit trotzdem komplett umschreibst)

— KajMagnus
quelle