Skip to content

Latest commit

 

History

History
72 lines (45 loc) · 3.76 KB

CONTRIBUTING.md

File metadata and controls

72 lines (45 loc) · 3.76 KB
Raw

Contribution Guide

Hi, we are excited that you are interested in contribution! This is a general contributing guidelines for one-zero-eight projects. Before submitting your contribution, please take a moment to read through this guide.

How can I contribute?

There are multiple ways how you can help:

  • 🐞 Report a bug or request a feature
    Go to the related repository and create a new issue for the bug/feature (go to Issues → New Issue).
  • 💡 Suggest an idea
    In case you belive we lack something at Innopolis, we have a one-zero-eight/roadmap repository, where you can open an issue to suggest your idea (your authorship will be preserved!).
  • ✍️ Send a feedback
    If you have something to say about our activity, projects or anything else, you can send a feedback with this Google Form.
  • 🧑🏻‍💻 Write code
    Pick up an issue from the board and continue reading this guide, if you want to send a pull request to one of our repositories.

Sending Pull Request

English only

Use English language everywhere on GitHub: in the code, comments, documentation, issues, PRs.

Why?


Most of us are Russian-speaking and we love Russian (🤍💙❤️), though we believe there are benefits of using English here:

  1. Bigger community: there are many non-Russian speaking students studying and living in Innopolis, and everyone should be able to contribute.
  2. Open-source: contributing to the global open-source community today is the crucial part of becoming a professional software engineer, and it's easier to so, if you use English.
  3. Finally, practicing a foreign language has many benefits by itself (boosting brain activity, career benefits, etc.).

Before you start

For features: before you start to work on a new feature, it's better to open a feature request issue first to discuss with the maintainers and other contributors whether the features is desired and decide on its design. This can save time for everyone and help features to be deliveried faster.

For small changes: it's better to batch multiple typo fixes and small refactoring changes into one pull request to keep the commit history clean.

Commit convention

We follow Conventional Commits for commit messages, which allows the changelogs to be auto-generated. Please read the guide if you aren't familiar with it already.

Note that fix and feat commit types are for actual code changes that affect logic. If your commit changes docs or fixes typos, use docs or chore instead:

  • fix: typo → docs: fix typo

Creating pull request

If you have troubles creating a pull request, this guide might help.

It's ok to have multiple commits in a single PR, you don't need to rebase or force push anything, because we will Squash and Merge the PR into one commit.

Title

Your title should also follow the Conventional Commits. An example of a good PR title would be:

feat: add animated snowfall background

Description

Make sure your PR have a clear description of the changes made and the reason behind them. If your PR closes an existing issue (e.g. #123), make sure to mention it using built-in GitHub functionality, so it will be automatically closed once the PR gets merged:

...

Fixes #123.