Skip to content

Submitting Changes

The last step of the contributing process is to submit your changes. This is done via a pull request on GitHub. A pull request basically is asking us to pull your changes into our codebase. Let's create one!

Push your changesπŸ”—

The first step is to push your changes to your fork on GitHub. You can do this using IntelliJ's Git integration.

Creating a Pull RequestπŸ”—

There are three ways to create a pull request:

  1. If you recently pushed to your fork, you see a Create Pull Request hint on our repository page.

  2. You can go to the Pull Request page on our repository and click on New Pull Request. But then you need to click on Compare across Forks and then select your Head Repository.

  3. You can also click on New Pull Request in your fork, then it already compares it to the BetonQuest repository.

Now give the pull request a short but meaningful title. Then add a description that indicates what you added, removed or changed. If there are related issues, link them with the keyword Closes #issue-id-here, so the issue is automatically closed when the pull request is merged.

Reviewer's ChecklistπŸ”—

The list below contains typical problems that we will check during the review. Do not click any of these boxes on GitHub, we will do that.

Please make sure that you fulfill these requirements. Did you...

... run Maven verify?

The most basic check is Maven Verify. Run it in you IDE and make sure it succeeds!

... test your changes?

Always test your changes in-game! Keep in mind, that there could be some special case in your code that needs to be tested specifically.

... update the changelog?

Don't forget to add a changelog entry for every change you made. Read maintaining the changelog for more information.

... update the documentation?

You need to adjust the documentation everytime you changed, added or removed any feature. Remember: Things that aren't documented don't exist to the user. There can also be other reasons why you should update the documentation, like writing a new tutorial or adjusting a bad example.

... adjust the ConfigUpdater?

Currently not relevant. We are working on a new updater.

... solve all TODOs?

You shouldn't have any TODOs in your code because it indicates that your code is not finished. Unfinished code is not added to the plugin. Let's see what to do with different types of TODOs / comments:

  • FIXME: Delete it -> Fix it or open an issue on GutHub.
  • DEPRECATED: Delete it -> Deprecate with @Deprecated and document it in the Javadocs.
  • Auto-generated code: Delete it.
  • NOT IMPLEMENTED: Delete it -> Implement or leave empty.
... remove any commented out code?

We use the version control system Git - it will remember any code. So don't even start committing commented out code.

... add debug messages?

In general, BetonQuest already has a lot of debug messages. So normally you do not need to add anything. It may be beneficial for new or complicated things.

... clean the commit history?

You did multiple commits, that look like progress fixing the bug? Or you did a commit with a wrong description?

Then you now need to do an Interactive Rebase. This changes the commit history. Here is the general git documentation for changing the history. But if you use IntelliJ, you should read edit Git project history.

In case you don't understand, read this guide that explains, why and how you clean the commit history.

Submit your Pull RequestπŸ”—

Now click on Create Pull Request to submit your request.

If you want to share work-in-progress changes to get early feedback, create a "draft pull request". Click on the arrow next to Create Pull Request and then select Create draft Pull Request. This indicates, that this pull request is not finished, and you can click on Ready for review once you are ready.

Congrats, you are done! Thank you for contributing! ❀

Keep an eye out for reviews of your pull request.