Skip to content

Latest commit

 

History

History
83 lines (59 loc) · 3.29 KB

File metadata and controls

83 lines (59 loc) · 3.29 KB

Contributing to the project

Thanks for taking the time to contribute! ✨

In this document you will find all the information you need to make sure the project continues to be the high-quality product we want to be!

Reporting features and issues

Issues

When reporting a problem, be as specific as possible. Ideally, you should provide a 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

Features are requested and handled via issue tickets.

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.

Pull Request

In general:

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 issue.

In the issue or feature request specify 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:

  1. Create an issue describing the bug or feature and state you would like to work on that.
  2. The team will cheer you and/or discuss with you the issue.
  3. Fork the project (if not done already).
  4. Clone your forked project and create a git branch.
  5. Make the necessary code changes in as many commits as you want. The commit message should follow conventional commits standard.
  6. Create a pull request. After reviewing your changes and making any new commits if needed, the team will approve and merge it.

Code Guidelines

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.