Thanks for taking the time to contribute! ✨
In this document you will find all the information you need to make sure that the projects continues to be consistent and with great quality!
Note
By contributing in this repository you accept the developer certificate of origin.
When reporting a problem, be as specific as possible. Ideally, you should provide an small snippet of code that reproduces the issue.
Please fill the default template so we can have all the required information to address the issue.
Features are requested and handled as GitHub issues.
If you want to ask for a new feature, first make sure it hasn't been reported yet by using the search box in the issue tab. Make sure that the feature aligns with the direction of the project.
Do not ask for tools for games or translations.
Before starting a pull request, create an issue requesting the feature you would like to see and implement. If you are fixing a bug, create also an issue to be able to track the problem.
In the issue or feature request specify that that you would like to work on it. The team will reply as soon as possible to discuss the proposal. This guarantee the Pull Request implementation match the direction the project is going.
In general, the process to create a pull request is:
-
Create an issue describing the bug or feature and state you would like to work on that.
-
The team will cheer you and/or discuss with you the issue.
-
Fork the project (if not done already).
-
Clone your forked project and create a git branch.
-
Make the necessary code changes in as many commits as you want. The commit message should follow this convention:
:emoji: Short description #IssueID Long description if needed.
-
Create a pull request. After reviewing your changes and making any new commits if needed, the team will approve and merge it.
For a complete list of emoji description see this repository.
The project includes a .editorconfig
file that ensures the code style is
consistent. It is supported in any modern IDE.
In general, we follow the following standard guidelines with custom changes:
And as the mono team says:
- It is more important to be correct than to be fast.
- It is more important to be maintainable than to be fast.
- Fast code that is difficult to maintain is likely going to be looked down upon.
Make sure to follow these tips:
- ✔️ DO write documentation for any public type and method.
- ✔️ DO write a test for all the possible code branches of your methods. Use a TDD approach.
- ✔️ DO seek for the maximum test coverage.
- ✔️ DO clean compiler warning.