zerokit/CONTRIBUTING.md

Contributing to Zerokit

Thank you for your interest in contributing to Zerokit! This guide will discuss how the Zerokit team handles Commits, Pull Requests and Merging.

Note: We won't force external contributors to follow this verbatim. Following these guidelines definitely helps us in accepting your contributions.

Getting Started

1. Fork the repository
2. Create a feature branch: git checkout -b fix/your-bug-fix or git checkout -b feat/your-feature-name
3. Make your changes following our guidelines
4. Ensure relevant tests pass (see testing guidelines)
5. Commit your changes (signed commits are highly encouraged - see commit guidelines)
6. Push and create a Pull Request

Development Setup

Prerequisites

Install the required dependencies:

make installdeps

Or use Nix:

nix develop

Building and Testing

# Build all crates
make build

# Run default tests
make test

# Module-specific testing
cd rln-wasm && cargo make test_utils    # Test utility functions
cd rln-wasm && cargo make test_browser  # Test in browser headless mode
cd rln-wasm && cargo make test_parallel # Test in browser parallel feature

Tools

We recommend using the markdownlint extension for VS Code to maintain consistent documentation formatting.

Commits

We want to keep our commits small and focused. This allows for easily reviewing individual commits and/or splitting up pull requests when they grow too big. Additionally, this allows us to merge smaller changes quicker and release more often.

All commits must be GPG signed. This ensures the authenticity and integrity of contributions.

Conventional Commits

When making the commit, write the commit message following the Conventional Commits (v1.0.0) specification. Following this convention allows us to provide an automated release process that also generates a detailed Changelog.

As described by the specification, our commit messages should be written as:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Some examples of this pattern include:

feat(rln): add parallel witness calculation support

fix(rln-wasm): resolve memory leak in browser threading

docs: update RLN protocol flow documentation

Scopes

Use scopes to improve the Changelog:

• rln - Core RLN implementation
• rln-cli - Command-line interface
• rln-wasm - WebAssembly bindings
• utils - Cryptographic utilities (Merkle trees, Poseidon hash)
• ci - Continuous integration

Breaking Changes

Mark breaking changes by adding ! after the type:

feat(rln)!: change proof generation API

Pull Requests

Before creating a pull request, search for related issues. If none exist, create an issue describing the problem you're solving.

CI Flow

Our continuous integration automatically runs when you create a Pull Request:

• Build verification: All crates compile successfully
• Test execution: Comprehensive testing across all modules and feature combinations
• Code formatting: cargo fmt compliance
• Linting: cargo clippy checks
• Cross-platform builds: Testing on multiple platforms

Ensure the following commands pass before submitting:

# Format code
cargo fmt --all

# Check for common mistakes
cargo clippy --all-targets

# Run all tests
make test

Adding Tests

Include tests for new functionality:

• Unit tests for specific functions
• Integration tests for broader functionality
• WASM tests for browser compatibility

Typos and Small Changes

For minor fixes like typos, please report them as issues instead of opening PRs. This helps us manage resources effectively and ensures meaningful contributions.

Merging

We use "squash merging" for all pull requests. This combines all commits into one commit, so keep pull requests small and focused.

Requirements

• CI checks must pass
• At least one maintainer review and approval
• All review feedback addressed

Squash Guidelines

When squashing, update the commit title to be a proper Conventional Commit and include any other relevant commits in the body:

feat(rln): implement parallel witness calculation (#123)

fix(tests): resolve memory leak in test suite
chore(ci): update rust toolchain version

Roadmap Alignment

Please refer to our project roadmap for current development priorities. Consider how your changes align with these strategic goals when contributing.

Getting Help

• Issues: Create a GitHub issue for bugs or feature requests
• Discussions: Use GitHub Discussions for questions
• Documentation: Check existing docs and unit tests for examples

License

By contributing to Zerokit, you agree that your contributions will be licensed under both MIT and Apache 2.0 licenses, consistent with the project's dual licensing.

Additional Resources

• Conventional Commits Guide
• Project GitHub Repository