Skip to content

Latest commit

 

History

History
86 lines (67 loc) · 3.8 KB

CONTRIBUTING.adoc

File metadata and controls

86 lines (67 loc) · 3.8 KB
Raw

Keep Contribution Guide

🎉 Thanks for taking the time to contribute! 🎉 Contributions are welcome from anyone, and even the smallest of fixes is appreciated!

The following is a set of guidelines for contributing to Keep and its packages. Feel free to propose changes to this document in a pull request.

Getting started

  1. Fork keep-network/tbtc-v2

  2. Clone your fork

  3. Each module has their own setup instructions. Follow the README of the specific module you want to contribute to.

  4. Set up the Development Tooling.

  5. Open a PR against the main branch and describe the change you are intending to undertake in the PR description.

Before marking the PR as ready for review, make sure:

  • It passes the linter checks (see Pre-commit to make this automatic).

  • It passes the continuous integration tests.

  • Your changes have sufficient test coverage (e.g regression tests have been added for bug fixes, unit tests for new features)

Development Tooling

Commits must be signed.

Continuous Integration

Keep uses Github Actions for continuous integration. All jobs must be green to merge a PR.

Pre-commit

Pre-commit is a tool to install hooks that check code before commits are made. It can be helpful to install this, to automatically run linter checks and avoid pushing code that will not be accepted. Follow the installation instructions here, and then run pre-commit install to install the hooks.

Linting

Linters and formatters for Solidity, JavaScript, and Go code are set up and run automatically as part of pre-commit hooks. These are checked again in CI builds to ensure they have been run and are passing.

If you want to change a rule, or add a custom rule, to the JavaScript or Solidity linting, please propose these changes to our solium-config-keep and eslint-config-keep packages. All other packages have it as a dependency.

Commit Messages

When composing commit messages, please follow the general guidelines listed in Chris Beams’s How to Write a Git Commit Message. Many editors have git modes that will highlight overly long first lines of commit messages, etc. The GitHub UI itself will warn you if your commit summary is too long, and will auto-wrap commit messages made through the UI to 72 characters.

The above goes into good commit style. Some additional guidelines do apply, however:

  • The target audience of your commit messages is always "some person 10 years from now who never got a chance to talk to present you" (that person could be future you!).

  • Commit messages with a summary and no description should be very rare. This means you should probably break any habit of using git commit -m.

  • A fundamental principle that informs our use of GitHub: assume GitHub will someday go away, and ensure git has captured all important information about the development of the code. Commit messages are the piece of knowledge that is second most likely to survive tool transitions (the first is the code itself); as such, they must stand alone. Do not reference tickets or issues in your commit messages. Summarize any conclusions from the issue or ticket that inform the commit itself, and capture any additional reasoning or context in the merge commit.

  • Make your commits as atomic as you can manage. This means each commit contains a single logical unit of work.

  • Run a quick git log --graph --all --oneline --decorate before pushing. It’s much easier to fix typos and minor mistakes locally.