Skip to content
This repository has been archived by the owner on Oct 1, 2024. It is now read-only.

Latest commit

 

History

History
49 lines (32 loc) · 2.39 KB

CONTRIBUTING.md

File metadata and controls

49 lines (32 loc) · 2.39 KB

Contribution guidelines

Contributions can be one of the following task: identifying an issue, creating an issue, solving an issue, or reviewing.

Identifying an issue

Correctly identifying issues can be as important as solving them. If you have found an issue or think an important feature is missing, documenting it can go a long way.

  1. You should search existing issues
  2. If there is an issue similar to yours
    • React to it with a 👍 to show your interest, as it helps prioritize
    • Comment below if you have a diverging opinion or additional details to characterize the issue
  3. If there is no issue that is similar to yours, then create one

An issue should ideally be small or be structured in small steps that do not need to be addressed all at once. The goal is to limit merge conflicts by frequently integrating commits, ease contributions by reducing their scope, and give a better visibility of what is left to do.

Creating an issue

The process to create an issue is the following:

  1. Create a new issue and choose between bug and feature request.
  2. Pick a fitting title.
  3. Add the appropriate labels.
  4. Fill the template issue. Not all fields are necessary, but the more information the better.

In the case of an issue that is composed of multiple steps, use tick boxes (lines starting with - [ ]). Github tracks the state of each boxes, and we can then do pull-requests that only ticks some of the boxes.

Solving an issue

Once you found an issue you want to work on, you should follow these steps:

  1. Create a new branch and push it to create a draft PR
  2. Mention the issue(s) you want plan to solve in the draft. Do not try to solve too many at once if it could take an unexpected amount of time, do multiple PRs instead.
  3. Commit your changes locally to solve the issue(s) and push frequently to update the PR as you go.
  4. Request a review from one of the contributors.
  5. Merge the PR once approved.

Except for PRs fixing critical issues and pressing bugs, you should try to give time for others to review before merging.

Reviewing

Reviewing PRs is always a good practice and helps building more robust code. If you see pending PRs, never hesitate to review them, add comments and suggest edits.

Contributors to contact

  • @Dodecahedr0x
  • @R-H-K
  • @metaproph3t
  • @0xbigz