Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
53 lines (28 loc) · 2.04 KB

CONTRIBUTING.md

File metadata and controls

53 lines (28 loc) · 2.04 KB

How to contribute

Issue Rules

When creating an issue, you must follow the given format :

  • The issue name must be as clear and understandable as possible :

    Create the Contributing.md

  • Describing the issue is mandatory and useful for everyone. Using a template for your issue is recommended.

  • Add corresponding labels to clarify the issue. If there is no label existing or corresponding to your issue, create one and describe it.

  • Take a moment to link the issue with the project, if it hasn't been done automatically.

Branch Rules

The branch name should consider the issue title and the issue number in its name. The issue's number must come first.

Example:

`2-Create-The-Contributing.md`

You must make one branch per issue.

Try to push as regularly as possible so everyone can see where you are at. When first committing to a branch, it is recommended to open a PR draft, so it will be easier for your mates to see where you are at.

Documentation

The documentation is mandatory for every function corresponding to the code rules. Everyone must be able to understand the utility of the function just by reading the function’s documentation.

Commit Rules

There is no specific rules about your commits messages format. Just be concise and clear.

We don't want something like 'Remove file'.

You should always commit frequently and based on the given example.

If possible, please certify your commits (-S).

Pull Request Rules

When your work is done on a branch, you must make a pull request.

The name should decribe the major scope of your modifications. With this, you must write a description as a reminder of what you have done. It may be all about the issue, but often you have unexpected fixes.

For the reviewers, prioritize the people who can really help you with your work.

You must have at least 1 reviewer who approve your pull request.

Try not to exceed 24 hours before reading your PRs.

It is obviously forbidden to approve a merge until all the reviewers have accepted the PR as well as the success of the workflows.