Author's note:
First off, many, many, many thanks for consider contributing to this plugin! I like to make things, but getting a hand on it is much better. I really appreciate that you are reading this file 🤗
The issue tracker is the preferred channel for bug reports, features requests and submitting pull requests, but please respect the following restrictions: Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved.
A bug is a demonstrable problem that is caused by the code in the repository. Good bug reports are extremely helpful. Try to keep in mind these suggestions when you want to report a bug:
- Use the GitHub issue search. Check if the issue has already been reported, and if it's already solved.
- Always open only one issue for one bug. This help us to keep clean solutions to specific problems.
- Don't forget to add information about your system, software and plugin version. The issue template can help you here.
- Describe your issue. What doesn't work, and how do you expect it to work instead?
- If suitable, include the steps required to reproduce the bug.
Feature requests are welcome! But this only applies if it's inside the scope of this plugin.
We can integrate a thing that will help you and other users to do something with the plugin, but we will not integrate something that:
- Only will works for you and no other user will be able to use it.
- Is out of the scope of this plugin idea.
As an example, improvements or requests related to documentation are always welcome.
Good pull requests - patches, improvements, new features - are a fantastic help.
Make sure that your pull request:
- Solves a common use case that several users will need in their real-life projects
Try to ask first before embarking on any significant pull request. Making those are hard and you risk spending a lot of time working on something that the project's developers might not want to merge into the project.
As an example, you don't need to ask to make a pull request that solves an issue, if your pull request fixes it, then you've already asked if it's going to be useful in the plugin.
Follow GDScript documentation comments guide to document what you did (if suitable).
If your pull request adds methods, properties, signals or new classes that can be used by any user, you must update the documentation reference to document those.
If your pull request modifies parts of the code in a non-obvious way, make sure to add comments in the code as well.
Try to make simple PRs that handle one specific topic. Just like for reporting issues, it's better to open 3 different PRs that each address a different issue than one big PR with three commits.
When updating your fork with upstream changes, please use git pull --rebase
to avoid creating "merge commits".
Take a look at this GIT Style guide and try to keep that in mind.