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:
If you recently pushed to your fork, you see a
Create Pull Requesthint on our repository page.
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 Forksand then select your
You can also click on
New Pull Requestin 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
so the issue is automatically closed when the pull request is merged.
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
@Deprecatedand 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
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.