Submitting a Pull-Request

The Basics

First you need to setup your machine to be able to develop for and with Sponge:

• read Preparing for Development and setup your machine
• get familiar with git and GitHub: How to Git(Hub)
• read our Code Style page and Contribution Guidelines
• get familiar with our Git Workflow for API and Implementations

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

Writing a PR

Fixing Bugs

Explain in a few sentences:

• which bug you encountered, especially
  • how it behaved
  • how you think it should behave
• what you fixed
• how you fixed it

Major API Addition

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).