Contribution Guidelines

Advarsel

This documentation refers to an outdated SpongeAPI version and is no longer actively maintained. While the code examples still work for that API version, the policies, guidelines, and some links may have changed. Please refer to the latest version of the documentation for those.

There will always be a need for developers to help us improve SpongeAPI. There is no such thing as a perfect project and things can always be improved. If you are a developer and are interested in helping then please do not hesitate. Just make sure you follow our guidelines.

Bemærk

Developers who show determination and consistency in their contributions to the project may be invited to join the Sponge Staff by Team Leaders, at their discretion. There is no formal application process. Please don’t ask to be staff, we’ll ask you.

Passos generals

  1. Setup your workspace as described in Klargøring til udvikling.

  2. Make sure you’re familiar with Git and GitHub. If your knowledge needs a refresh, take a look here: How to Git(Hub)

  3. Check for existing issues in the SpongeAPI, SpongeCommon, SpongeForge, SpongeVanilla, and SpongeDocs repositories. There is possibly someone else already working on the same thing. You can also check issues marked with »help wanted« for existing issues we need your help with.

Bemærk

Please don’t submit pull request for small changes under 20 lines. Instead, join #sponge on IRC (irc.esper.net) or join #spongedev on IRC (irc.esper.net) and we’ll change it together with the other smaller changes.

  1. Si el problema requereix un canvi molt gran, és possible que vulgueu presentar els problemes sense els canvis necessaris aplicats, per poder confirmar el problema i saber que vostè està treballant per solucionar-ho. També ha de crear un WIP (treball en procés, en anglès) posi la petició amb el prefix [WIP] per a que puguem començar a revisar-ho.

  2. Extregui o ancli el projecte, cloni’l i feu els canvis en una branca addicional.

  3. Test your changes (make sure it compiles!), commit and push them to your fork.

  4. Submit the pull request with a short summary what you’ve changed and why it should be changed in that way.

  5. If you make additional changes, push new commits to your branch. Do not squash your changes, that makes it extremely hard to see what you’ve changed compared to the previous version of your pull request.

  6. Make sure your PR is rebased to the latest changes of the branch you’re intending to merge it into. If you need help rebasing it, just ask!

Tip

If you’re unsure which branch you should base your work on, read about our Versioning System and Repository Branch Layout before submitting your PR.