Einen Änderungsvorschlag einreichen

Warnung

Dieses Dokument bezieht sich auf eine veralte SpongeAPI-Version und wird nicht länger aktiv gepflegt. Während die Code-Beispiele für diese API-Version immer noch funktionieren, die Richtlinien und einige Links haben sich möglicherweise geändert. Bitte gehe stattdessen zur aktuellen Version der Dokumentation.

Die Grundlagen

Als erstes musst du deinen Rechner so einrichten, dass du für und mit Sponge entwickeln kannst:

• Lese Vorbereitung für die Entwicklung und richte deinen Rechner ein

• Mach die vertraut mit git und GitHub: Wie man Git(Hub)t

• Lese unsere Code Style Seite und Richtlinien für Beiträge

• Mach die vertraut mit unserer Der Git Arbeitsablauf für die API und die Implementierungen

Wenn du damit fertig bist und du dich bereit fühlst für Sponge zu entwickeln, entscheide dich, an welchem Teil du arbeiten möchtest.

Einen Änderungsvorschlag schreiben

Bugs fixen

Erkläre in wenigen Sätzen:

• Auf welchen Bug du gestoßen bist, insbesondere

  • Was geschehen ist

  • Was du denkst, dass geschehen sollte

• Was du geändert hast

• Wie du es repariert hast

Größere API Erweiterungen

Nun, du hast also eine relativ große Ergänzung der API entwickelt, die du als Änderungsvorschlag einreichen möchtest. Gut! Konstruktive PRs sind das, was dieses Projekt stetig verbessert. Was uns zum schreiben der glorreichen PR Beschreibung führt.

In der Vergangenheit gab es bereits einige, die weit über den Standard lagen. Hier ein paar Beispiele:

• Inventory API PR

• Data API PR

Natürlich sind dies Extrembeispiele. Aber hier sind auch akzeptiere PRs, die einen guten Standard vorgeben, von dem was in einer PR Beschreibung enthalten sollte:

• Event Filtering PR

• Bans improvement API PR

Ein paar Punkte, die wir hiervon ableiten können sind:

• Links zu jeglichen Implementierungs-PR sind deutlich sichtbar am Anfang des PR. Dies kann durch Verwendung von GitHub Markdown erreicht werden

*SpongeAPI*|[SpongeCommon](html link)|[SpongeForge](html link)|[SpongeVanilla](html link)

• Eine klare Beschreibung, was das Ziel des API PR ist. Dies sollte eine kurze Zusammenfassung sein, ähnlich wie wenn du einen Aufsatz schreibst, maximal 4 Sätze lang, abhängig von der Funktion um welche es geht.

• Ein einfaches Code Beispiel, wie Plugins diese neue Feature verwenden können (und falls es es bereits ähnliche Features gibt, warum diese geändert werden müssen).