If you are reading this document right now, you are probably considering contributing to Mainsail and making it better than it is today. Thank you for taking that initiative! Before submitting your contribution, please take a moment and make sure to read through our contribution guidelines:
- Code of Conduct
- Question or Problem?
- Issues and Bugs
- Feature Requests
- Submission Guidelines
- Financial Contributions
- Credits
Please do not open issues for general support questions. We want to keep GitHub issues for bug reports and feature requests. Instead, please visit us on Discord to ask support-related questions.
Our Discord server is a much better place to ask general support questions. We take a right to close issues that are requests for generic support and redirect people to Discord.
If you find a bug in the source code or think that Mainsail is behaving odd in specific situations, you can help us fix that issue by submitting an issue. If you have already fixed that issue, you can submit a Pull Request with that fix.
You can request a new feature by submitting a feature request. If you would like to implement a new feature, please consider the scope of the change. For changes requiring a lot of work, it's best to outline a proposal first so it can be discussed. This allows us to prevent wasted time and effort and discuss how to bring your proposed feature into the project.
Before you submit an issue, please search the issue tracker if your problem may already exist. If a ticket already covers your case, please refrain from opening a new ticket and instead contribute to the existing ticket. If you submit an issue, please provide the required information and reproduction steps. We need those to be able to try and reproduce the bug ourselves. Without proper instructions on how to reproduce the issue you are encountering, we might be unable to fix a possible bug.
Before you work on a PR and submit it, please pay attention to the following guidelines:
-
Search the pull requests for an open or closed PR related to your submission.
- You don't want to duplicate existing efforts or work on something unlikely to be merged into the project.
-
Do not submit PRs against the
master
branch. PRs need to be submitted against thedevelop
branch. -
Follow our Code Standards
-
If there is an issue describing the problem you're fixing or a discussion of a feature you are implementing, make sure to link it in the PRs body.
- You can also add
fix #<id>
orfixes #<id>
in the PR body where<id>
is the issue id. - Example PR title, body and sign-off:
fix: incorrect handling of click event This PR will fix #123. Fixes correct handling of click event when button [X] is clicked. Signed-off-by: James Smith <james.smith@myvalidemail.com>
- You can also add
-
If there is no issue describing the problem, create an issue first or provide a sufficient description of the bug/feature.
- Screenshots of your changes are welcome if you worked on UI-related code.
-
The title of the PR should follow the commit message convention.
- If the PR consists of multiple commits, it's good practice to follow the convention, although that is not necessarily required.
- Upon merging, we will squash all commits of the PR into a single commit for a clean history and release changelogs.
-
Please sign off each commit and your PR. It must contain your real name and a current email address (see example in item 4).
- The sign-off should follow this pattern:
Signed-off-by: My Name <myemail@example.org>
- The sign-off certifies that you agree with the developer certificate of origin.
- If you provide a translation, a sign-off is not necessarily required.
- The sign-off should follow this pattern:
-
When opening a pull request, keep
Allow edits and access to secrets by maintainers
enabled.
As a community-driven project without primary corporate backing, we always welcome financial contributions. A list of options we offer to support us financially can be seen below.
- Become a supporter on Patreon (monthly recurring)
- Donation via Ko-Fi (one time / monthly recurring)