10. Join the Community

First off, thanks for taking the time to contribute!

The following is a short set of guidelines for contributing to Iroha.

10.1. How Can I Contribute?

10.1.1. Translating Documentation

Here you can translate Iroha documentation into your language – community will be grateful for your help! Instructions are included – just follow the link to the repository.

10.1.2. Reporting Bugs

Bug is an error, design flaw, failure or fault in Iroha that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

Bugs are tracked as GitHub issues (this is the preferred option) or as JIRA issues (if it is convenient to you). in Hyperledger Jira.

If you decide to go with the GitHub issues, just click on this link and follow the instructions in the template.

To submit a bug, create new issue and include these details:

Field

What to enter

Project

Iroha (IR)

Issue Type

Bug

Summary

Essence of the problem

Description

What the issue is about; if you have any logs, please provide them

Priority

You can use Medium though if you see the issue as a high priority, please choose that

Environment

Your OS, device’s specs, Virtual Environment if you use one, version of Iroha etc.

10.1.3. Reporting Vulnerabilities

While we try to be proactive in preventing security problems, we do not assume they’ll never come up.

It is standard practice to responsibly and privately disclose to the vendor (Hyperledger organization) a security problem before publicizing, so a fix can be prepared, and damage from the vulnerability minimized.

Before the First Major Release (1.0) all vulnerabilities are considered to be bugs, so feel free to submit them as described above. After the First Major Release please utilize a bug bounty program here in order to submit vulnerabilities and get your reward.

In any case ? feel free to reach to any of existing maintainers in Rocket.Chat private messages or in an e-mail (check CONTRIBUTORS.md file) if you want to discuss whether your discovery is a vulnerability or a bug.

10.1.4. Suggesting Improvements

An improvement is a code or idea, which makes existing code or design faster, more stable, portable, secure or better in any other way.

Improvements are tracked as GitHub issues (this is the preferred option) or as JIRA improvements.

Again, if you choose GitHub issues, just click on this link and follow the instructions in the template.

To submit a new improvement in JIRA, create new issue and include these details:

Field

What to enter

Project

Iroha (IR)

Issue Type

Improvement

Summary

Essence of the idea

Description

What the idea is about; if you have any code suggestions, you are welcome to add them here

Priority

You can use Medium

Assign

You can assign the task to yourself if you are planning on working on it

10.1.5. Asking Questions

A question is any discussion that is typically neigher a bug, nor feature request or improvement. If you have a question like “How do I do X?” - this paragraph is for you.

Please post your question in your favourite messenger so members of the community could help you. You can also help others!

10.1.6. Your First Code Contribution

Read our C++ Style Guide and start with checking out the GitHub board or the beginner-friendly issues in JIRA with good-first-issue label. Indicate somehow that you are working on this task: get in touch with maintainers team, community or simply assign this issue to yourself.

10.1.7. Pull Requests

  • Fill in the required template

  • End all files with a newline

  • Write tests for new code. Test coverage for new code must be at least 70%

  • Every pull request should be reviewed and get at least two approvals from maintainers team. Check who is a current maintainer in MAINTAINERS.md file

  • When you’ve finished work make sure that you’ve got all passing CI checks ? after that squash and merge your pull request

  • Follow the C++ Style Guide

  • Follow the Git Style Guide

  • Document new code based on the Documentation Styleguide

  • When working with PRs from forks check this manual

10.2. Styleguides

10.2.1. Git Style Guide

  • Sign-off every commit with DCO: Signed-off-by: $NAME <$EMAIL>. You can do it automatically using git commit -s

  • Use present tense (“Add feature”, not “Added feature”).

  • Use imperative mood (“Deploy docker to…” not “Deploys docker to…”).

  • Write meaningful commit message.

  • Limit the first line of commit message to 50 characters or less

  • First line of commit message must contain summary of work done, second line must contain empty line, third and other lines can contain list of commit changes

  • When merging to destination branche: use Squash and merge

10.2.2. C++ Style Guide

10.2.3. Documentation Styleguide

  • Use Doxygen.

  • Document all public API: methods, functions, members, templates, classes…

10.3. Places where community is active

Our community members are active at:

Service

Link

RocketChat

https://chat.hyperledger.org/channel/iroha

StackOverflow

https://stackoverflow.com/questions/tagged/hyperledger-iroha

Mailing List

hyperledger-iroha@lists.hyperledger.org

Gitter

https://gitter.im/hyperledger-iroha/Lobby

Telegram

https://t.me/hl_iroha

YouTube

https://www.youtube.com/channel/UCYlK9OrZo9hvNYFuf0vrwww

Discord

https://discord.com/channels/905194001349627914/905205848547155968


Thank you for reading the document!