Contribution Guideline

Introduction

First, thank you for considering contributing to our Official/Community SDK/Library!

It is people like you that make the open-source community such a great community! 😊

We welcome any type of contribution, not just code. You can help with:

• QA: file bug reports, the more details you can give the better (e.g. screenshots with the console open)
• Marketing: writing blog posts, how-to's, printing stickers, ...
• Community: presenting the project at meetups, and organizing a dedicated meetup for the local community, ...
• Code: take a look at the open issues. Even if you can't write code, commenting on them and showing that you care about a given issue matters. It helps us triage them.

Your First Contribution

Working on your first Pull Request? You can learn how from this free series: How to Contribute to an Open Source Project on GitHub.

Submitting code

Any code change should be submitted as a pull request. The description should explain what the code does and give steps to execute it. The pull request should also contain tests.
Code review process

The bigger the pull request, the longer it will take to review and merge. Try to break down large pull requests in smaller chunks that are easier to review and merge. It is also always helpful to have some context for your pull request. What was the purpose? Why does it matter to you?

WARNING

Mono's Community/Official SDKs or libraries use conventional commits as a format commit message.

Release notes and tagging versions are based on the message commits. If you don't follow the format, our CI won't be able to increment the version correctly and your feature won't be released.

To write your commit message, see convention page here

Questions

If you have any questions, create an issue (protip: do a quick search first to see if someone else didn't ask the same question before!). You can also reach us via [email protected] or join our slack community channel via here.

Submitting your PR

Create the PR on the production branch. A valid PR must follow these points:

• Unit test is correctly implemented and covers the new scenario.
• If the code introduces a new feature, please describe the feature in the PR description.
• The commit message follows the conventional commits format.

The review always takes priority over other tasks. We can validate the PR very quickly if everything is clear and it's aligned with the evolution/vision of the framework.

Code of Conduct

Please be mindful of our Code of Conduct. This is your community, treat others with respect.