Skip to content

Latest commit

 

History

History
132 lines (96 loc) · 6.38 KB

CONTRIBUTING.md

File metadata and controls

132 lines (96 loc) · 6.38 KB
Raw

Contributing to ink!

First of all, thank you for taking your time to contribute to ink!

I don't want to contribute, I just have some questions! :S

Table of Contents

Code of Conduct

We are a friendly and welcoming open source community. You can find our code of conduct here.

During Development

Commits

Don't be afraid to have a bunch of commits while working on a pull-request. We end up squashing all of them before merging to the master branch anyways.

But please keep your commits small and descriptive. A good rule of thumb is to bundle semantic changes together in one commit. It makes the review process easier - which means you get a 🟩 from Github sooner (that's why you're contributing in the first place anyways, right?)

To help you out here's a really good post on how to write good commit messages.

Checklist

Below is a checklist for you before doing a pull request.

Following these will ensure that your pull request is going to be accepted.

  1. Run rustfmt automatically.
  2. Run clippy on your changes.
  3. Run tests via cargo test --release for off-chain testing.
  4. For critical parts perform some manual on-chain tests.
  5. Build the code and run tests also for the wasm32 target.
  6. Try to run some examples and see if they are still working correctly.
  7. Sometimes clippy lints can be unfortunate or even buggy and it can be very hard to fix those. In these situations you may skip the clippy lint with #[clippy::skip], however, note that this always requires a good rational as a side-comment and probably link to the eventual clippy bug.
  8. Important Strive for simple, clean and concise code. If your code is very complex - because it is trying to accomplish complex things - try to think about how another aproach or design could simplify it.
  9. We won't accept a pull request with FIXME or TODO comments in it. Please try to fix them by yourself and resolve all remaining to-do items. If that is not possible then write an issue for each of them and link to the source line and commit with a proper description. For more information go here.
  10. Document everything properly that you have written, refactored or touched. Especially keeping documentation up-to-date is very important. For larger portions please try to also update the ink! wiki or write a new entry there.
  11. Write tests for your code. If your code is hard to test, try to find a design that allows for testing.
  12. If needed also update the README.
  13. For performance critical parts we also want additional performance tests.
  14. If you implement a fix for a reported bug also include a regression test alongside the fix if possible.
  15. When commenting or documenting code make use of proper punctuation. This might seem pedantic but we believe that in essence this is going to improve overall comment and documentation quality.
  16. If possible try to sign your commits, e.g. using GPG keys. For more information about this go here.

Continuous Integration

Our continuous integration (CI) will check for the following properties of all changes.

  1. Is rustfmt happy with it ?
    • cargo fmt --all
  2. Is clippy happy with it?
    • cargo clippy --all-targets --all-features
  3. Does the code still compile?
    • cargo check --all-features
  4. Do all the examples still compile?
    • cargo +nightly contract check --manifest-path ./examples/.../Cargo.toml
  5. Is the wasm-32 target still compiling?
    • cargo check --no-default-features --target wasm32-unknown-unknown
  6. Are all the tests passing?
    • cargo test --all-features --workspace
  7. Are all the tests for the examples passing?
    • cargo +nightly test --manifest-path ./examples/.../Cargo.toml
  8. Is the test code coverage increasing or at least stable?
  9. Has the size of the example contract binaries changed?

Only if our very demanding CI is happy with your pull request we will eventually merge it. Exceptions confirm the rule!

Issues and Pull Requests

Please always respect our code of conduct when writing issues and pull requests or taking part in any kind of discussion.

Issues

You want to write an issue if you have a

  • feature request
  • bug report
  • technical question

about the ink! project.

Please use GitHub's search functionality to see if the question has already been asked, the feature has already been proposed or the bug has already been reported.

Make use of the accompanied issue template.

Pull Requests

Before working on a pull request please make sure that the work has not already been made, e.g. by another pull request solving the same thing.

For complex implementations you are advised to first discuss the feature implementation or bug fix using an issue.

A pull request should be doing or implementing exactly one semantic issue. So for example, when you refactor the code base in a pull request you should not also include code formattings into the same pull request.

It's totally fine to extract changes made in one pull request to multiple pull requests. It makes the review process easier (and hey, more 🟩 for you!).

If you've already opened a pull request, avoid force-pushing any new changes.

For a nice list of hints visit this link.

I don't want to contribute, I just have some questions

For questions about the ink! project, about Parity Technologies or general technical related questions you are welcome to contact us via Element. For technical questions specifically about the ink! and its sub-projects you may also file an issue. For more information about filing issues go here.