Skip to content

Latest commit

 

History

History
71 lines (45 loc) · 3.13 KB

CONTRIBUTING.md

File metadata and controls

71 lines (45 loc) · 3.13 KB
Raw

Guidelines for contributing

Reporting bugs

Before reporting a bug, try to search for a similar problem in the Issues section on GitHub. Clear the search bar to include closed issues in the search and type your phrase. When you click on New issue, several templates will be displayed — please pick Bug Report. Carefully fill out the template and submit the issue.

Requesting features

If you have an idea for improvement, you can submit your proposal in the Issues section on GitHub. When you click on New issue, several templates will be displayed — please pick Feature Request. Carefully fill out the template and submit the issue.

Local development environment setup

Please follow instructions specified in the README file and you are good to code!

Ephemeral development environment

You are more then welcome to contribute to our codebase from the cloud!
We set up an ephemeral Gitpod environment for all the developers who prefer coding from a remote server.

Just click on this cool button below:
Open in Gitpod

See more information on how to start up a Gitpod environment dedicated to a specific remote branch here, specific issue here and a specific pull request here.

However, please remember that such luxury is limitted:

Gitpod offers a free plan for new users which includes 50 hours of standard workspace usage. If you need more hours, you can upgrade to one of the paid plans in your personal settings.

Branch naming convention

You can read about git branching under this address. The branch names should follow the convention specified below:

<type>/<issue id>/<short description>

where

  • type is one of the Conventional Commits' types, i.e. feat, ci, docs, fix, refactor, test, chore, etc.
  • issue id is the id of the issue which will be fixed by this PR.
  • short description is ~25 characters long at max and is hyphenated.

Examples:

chore/6/gitignore
docs/22/contributing-instructions
refactor/8/initial-project-structure

Commit messages

In an effort to increase consistency, simplify maintenance and enable automated change logs, we would like to kindly ask you to write semantic commit messages, as described in the Conventional Commits specification (link above).

The general structure of Conventional Commits is as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer]

Merging the pull request

A pull request can only be merged after it completed all of the checks performed by CI.
After a manual review by one of the maintainers, it can be merged into master.