Skip to content

Latest commit

 

History

History
186 lines (136 loc) · 7.15 KB

CONTRIBUTING.md

File metadata and controls

186 lines (136 loc) · 7.15 KB
Raw

Contributing

The HydraDX project is an Open Source Project if you'd like to help us please follow these rules so that our lives are easy

Code of Conduct

Help us keep HydraDX open and inclusive. Please read and follow our coc.

Got a Question or Problem?

Do not open issues for general support questions as we want to keep GitHub issues for bug reports and feature requests. You've got much better chances of getting your question answered on Discord.

Found a Bug?

If you find a bug in the source code, you can help us by submitting an issue to our repository. Even better, you can submit a PR with a fix.

Missing a Feature?

You can request a new feature by submitting an issue to our GitHub Repository. If you would like to implement a new feature, please submit an issue with a proposal for your work first, to be sure that we can use it. Please consider what kind of change it is:

  • For a Major Feature, first open an issue and outline your proposal so that it can be discussed. This will also allow us to better coordinate our efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project.
  • Small Features can be crafted and directly submitted as a Pull Request.

Submission Guidelines

Submitting an Issue

Before you submit an Issue, please search Issues for an open or closed Issue in this repository. Please use the provided templates to create new issues.

Submitting a Pull Request (PR)

Before you submit your Pull Request (PR) consider the following guidelines:

  1. Search GitHub for an open or closed PR that relates to your submission. You don't want to duplicate effort.

  2. Please sign our Contributor License Agreement (CLA) before sending PRs. We cannot accept code without this. Make sure you sign with the primary email address.

  3. Fork the repository.

  4. Make your changes in a new git branch:

    git checkout -b fix/my-branch master

  5. Create your patch, including appropriate test cases.

  6. Follow our Coding Rules.

  7. Run the respective test suites and make sure it passes.

  8. Use respective formatting tools to format the code.

  9. Commit your changes using a descriptive commit message.

    git commit -a

    Note: the optional commit -a command line option will automatically "add" and "rm" edited files.

  10. Push your branch to GitHub:

    git push origin fix/my-branch

  11. In GitHub, send a pull request to master or main branch.

  12. Make sure the PR name follows conventional commit format

  13. Make sure you bumped the correct versions. We're following SemVer

  • If we suggest changes then:
    • Make the required updates.
    • Re-run the test suites to ensure tests are still passing.

That's it! Thank you for your contribution!

After your pull request is merged

After your pull request is merged, you can safely delete your branch and pull the changes from the main (upstream) repository:

  • Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:

    git push origin --delete fix/my-branch

  • Check out the master branch:

    git checkout master -f

  • Delete the local branch:

    git branch -D fix/my-branch

  • Update your master with the latest upstream version:

    git pull --ff upstream master

Individuals making significant and valuable contributions are given commit-access to the project to contribute as they see fit.

Coding Rules

To ensure consistency throughout the source code, keep these rules in mind as you are working:

  • All features or bug fixes must be tested by one or more specs unit tests.
  • All module API methods must be documented.
  • Please follow our style guide

Pull Request Naming Guidelines

We have very precise rules over how our git pull request names can be formatted. This leads to more readable messages that are easy to follow when looking through the project history. But also, we use the git merge commit messages to generate the change logs.

The format

Each pull-request name consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:

<type>(<scope>)<breaking-change-indicator>: <subject>

Samples:

ci(changelog): generate changelog

fix(amm): fix benchmarking

feat(claim)!: add possibility to change claim data
  • Note that last message indicates a breaking change

Type

Must be one of the following:

  • build: Changes that affect the build system or external dependencies (example scopes: cargo, substrate)
  • ci: Changes to our CI configuration files and scripts (example scopes: gh-actions, bench-bot)
  • docs: Documentation only changes
  • feat: A new feature
  • fix: A bug fix (example scopes: amm, claims)
  • perf: A code change that improves performance
  • refactor: A code change that neither fixes a bug nor adds a feature
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • test: Adding missing tests or correcting existing tests (example scopes: amm, claims)

Scope

The scope should be the name of the affected module (as perceived by the person reading the changelog generated from merge commit messages). If the PR touches more than one thing, leave it blank and try to use subject to describe the change.

Subject

The subject contains a succinct description of the change:

  • use the imperative, present tense: "change" not "changed" nor "changes"
  • don't capitalize the first letter
  • no dot (.) at the end

Breaking Changes add ! after the scope

SemVer

We're following SemVer specification to keep us and our dependencies sane.

  • please bump respective version of the closest package file (cargo.toml or package.json).
  • if the change is a breaking change, always change the MAJOR version and bump version of packages above the package it's using. Follow this guideline to the root of the repository.
  • if in the Node repository, bump impl_version (non-breaking change) and spec_version (breaking-change) in the runtime/lib.rs respectively.

We're thankful for any meaningful contribution

Feedback for this guide is welcome! If you believe you have something valuable to add or change, please open a PR.

These contributing guidelines are modified from the Angular guidelines.