Een pull-request indienen

De basis

Eerst moet u uw machine gereed maken om te kunnen ontwikkelen voor en met Sponge:

• lees Voorberedingen voor Ontwikkeling en maak uw machine gereed

• raak getrouwd met Git en GitHub: Hoe u Git(Hub) moet gebruiken

• lees onze code conventies pagina en Richtlijnen voor het bijdragen

• raak vertrouwd met onze Git Workflow voor API en implementaties

When you’re done and feel you’re ready for developing Sponge, decide which parts you want to work on.

Het schrijven van een PR

Het oplossen van bugs

Verduidelijk in een paar zinnen:

• welke bug u heeft gevonden, en vooral

  • hoe het zich heeft gedragen

  • wat denk je wat er had moeten gebeuren

• wat heb jij gefixed

• hoe heb je het gefixed

Grote API toevoeging

So, you’ve developed a pretty large API addition that you want to now submit as a PR. Good! Constructive PR’s are what make this project keep getting better. Which brings us to writing the glorious PR description.

There have been a few in the past that go above and beyond the standards, examples include:

• Inventory API PR

• Data API PR

Of course, those examples are the extreme, but PR’s that are accepted and provide as a good standard of what should be included in a PR description are:

• Event Filtering PR

• Bans improvement API PR

A few things that can be taken from this:

• Links to any implementation PRs in clear view at the top of the PR, this can be achieved with GitHub Markdown

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

• Clear description of what the API PR is aiming to do, this can be a brief summary as if writing an essay, at most 4 sentences long, depending on what the functionality is.

• Clear code examples of how plugins can use the new feature (and if there are old features existing, why they needed to be changed).