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
Abstract: Report issues if no one have faced that issue before, else comment the opened issue; request stuff if you find it suitable and goes in the same way as this project goal; open pull request for opened issues of to improve/fix stuff that follows the same goal as this project and, please, document what you do, in the code or in the commit.
Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved. Is not a strict rule, but serves as guide to keep a structure.
- The issue tracker is the preferred channel for bug reports, features requests and submitting pull requests.
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.
- 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 project.
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. A command to show show a sprite? Sure. A command that connects to your specific server? I don't think others will find it useful.
-
Is out of the scope of this plugin idea. No, we can't bake a cake for you with this project, sorry.
As an example, improvements or requests related to documentation are always welcome.
Good pull requests (a.k.a 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. In other words, that works in more than one (1) project.
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.
Maintainers always try to guide other contributors about the ways that can be used to solve the issue, so you can use that information as guide when creating the pull request.
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.
Author note: This contribution guideline is based on many other open source projects. We show it as a guideline and not as a strict rule to follow.
Please refer to overview file to know the project structure in detail.