Einen Änderungsvorschlag einreichen
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:
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:
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).