Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
140 lines (93 loc) · 9.45 KB

CONTRIBUTING.md

File metadata and controls

140 lines (93 loc) · 9.45 KB
Raw

Contributing to SRI (Stratum V2 Reference Implementation)

First off, thanks for taking the time to contribute! ❤️

All types of contributions are encouraged and valued. See the Table of Contents for different ways to help and details about how this project handles them. Please make sure to read the relevant section before making your contribution. It will make it a lot easier for us maintainers and smooth out the experience for all involved. The community looks forward to your contributions. 🎉

And if you like the project, but just don't have time to contribute, that's fine. There are other easy ways to support the project and show your appreciation, which we would also be very happy about:

  • Star the project
  • Tweet about it
  • Refer this project in your project's readme
  • Mention the project at local meetups and tell your friends/colleagues

Table of Contents

I Have a Question

If you want to ask a question, we assume that you have read the documentation available at stratumprotocol.org/docs.

Best way to ask a question is to hop onto our community Discord. Two most suitable places to post a question are:

  • #newbies-qs and
  • #dev, for technical questions, suitable for developers building on top of SRI, or contributing to it.

If you then still feel the need to ask a question and need clarification, we recommend the following:

  • Open an Issue.
  • Provide as much context as you can about what you're running into.

We will then take care of the issue as soon as possible.

What Should I Know Before I Get Started

Important Resources About SRI

In order to have a better overview about what SRI covers, have a look at the following resources before getting started with contributions.

  • Stratum V2 Protocol Specifications.
    • Studying SV2 specs can take some time and requires effort, but it's the best way to properly understand what SV2 is about and how it's composed.
  • SRI Getting-started guide.
    • This can be explored in the meantime of SV2 protocol study, so that it can help getting a general overview about SV2. Moreover, it's the best way to really understand how SRI project is built on.
  • Stratum V2 Master Degree Thesis (by @gitgab19).
    • This resource can be useful to get some knowledge about Bitcoin mining, pooled mining protocols history, and Stratum V2.
  • Stratum V2 Explained - Videos Playlist (by @plebhash).
    • This is a series of videos explaining Stratum V2 in depth, which cover the aforementioned topics.

Project Communications

Most project communications happen in our Discord server. Communications related to general development typically happen under dev channel.

Discussion about specific codebase work happens in GitHub issues and on pull requests.

Our dev calls are scheduled every Tuesday at 18.00 CET. You can see them in the sidebar under Events on Discord and subscribe to them to be notified.

I Want To Contribute

When contributing to this project, you must agree that you have authored 100% of the content, that you have the necessary rights to the content and that the content you contribute may be provided under the project license.

Project Structure

It's possible to contribute to SRI opening PRs on three different repositories:

Contribution workflow

The SRI project follows an open contributor model, where anyone is welcome to contribute through reviews, documentation, testing, and patches. Follow these steps to contribute:

  1. Fork the Repository

  2. Create a Branch

  3. Commit Your Changes

    Note: Commits should cover both the issue fixed and the solution's rationale. These guidelines should be kept in mind.

  4. Run Tests, Clippy, and Formatter:

    cargo test: this command runs the project's test suite. Ensure that all tests pass without errors.

    cargo clippy: Clippy is a linter tool for detecting common mistakes and style issues. Address any warnings or errors reported by Clippy.

    cargo fmt: this command formats your code according to the project's style guidelines. Make sure to run this command to ensure consistency in code formatting.

  5. Submit a Pull Request: once you're satisfied with your changes, submit a pull request to the original SRI repository. Provide a clear and concise description of the changes you've made. If your pull request addresses an existing issue, reference the issue number in the description. In order to contribute to the protocol implementation, every PR must be opened against main branch.

  6. Review and Iterate

  7. Merge and Close: Once your pull request has been approved and all discussions have been resolved, a project maintainer will merge your changes into the main branch. Your contribution will then be officially part of the project. The pull request will be closed, marking the completion of your contribution.

Versioning and public dependencies

Whenever submitting a PR that modifies some crate, it's up to the contributor to make sure the versioning of this crate remains sane. The main factors to take into account are:

  1. According to SemVer 2.0.0 and the modifications on this PR, what kind of version bump does this crate deserve?
  2. Avoiding redundant version bumps:
    • Has the version of crate already been bumped on this repo since it was last published to crates.io?
    • If yes, do the changes introduced by this PR require a larger bump than the one already made?
  3. Keeping sanity across dependency chains:
    • Which other crates on this repo depend on this crate?
    • Amongst them, are there types from this crate exposed on their public APIs?

Factors 1 and 2 are partially enforced via CI (but enforcement via PR review is still encouraged). Factor 3 must be fully enforced via PR reviews.

Factor 2 is about avoiding redundant version bumps. Since crates are only published to crates.io periodically (during global release), maybe other PRs already bumped this crate version.

Factor 3 is about keeping sanity across dependency chains. If a crate only uses a dependency internally, updating that dependency does not automatically require an incompatible version bump for the dependent crate. However, if a dependency appears in the dependent crate's public API, then changing that dependency to an incompatible version also changes the dependent crate's public API.

Public API exposure includes, but is not limited to:

  • re-exports;
  • public function or method arguments and return types;
  • public trait method signatures;
  • public enum variant payloads;
  • public struct fields;
  • public type aliases and associated types.

For crates that are already 1.0.0 or above, an incompatible version bump means a MAJOR bump. For 0.x.y crates, an incompatible version bump usually means a MINOR bump, for example 0.2.3 -> 0.3.0. A PATCH bump on a 0.x.y crate is still treated as compatible within the same minor line, for example 0.2.3 -> 0.2.4.

Your First Code Contribution

In order to contribute, a basic learning about git and github is needed. If you're not familiar with them, have a look at https://docs.github.com/en/get-started/start-your-journey/git-and-github-learning-resources to dig into and learn how to use them.

Unsure where to begin contributing to SRI? You can start by looking through good first issue and help wanted issues:

  • Good first issue are issues which should only require a few lines of code, and a test or two.
  • Help wanted - issues which should be a bit more involved than good first issue issues.

Another way to better understand where to focus your contribution is by looking at our roadmap: https://github.com/orgs/stratum-mining/projects/5