secretumvault/CONTRIBUTING.md
2025-12-29 04:19:26 +00:00

3.3 KiB

Contributing to SecretumVault

Thank you for your interest in contributing! This document provides guidelines and instructions for contributing to this project.

Code of Conduct

This project adheres to a Code of Conduct. By participating, you are expected to uphold this code. Please see CODE_OF_CONDUCT.md for details.

Getting Started

Prerequisites

  • Rust 1.70+ (if project uses Rust)
  • NuShell (if project uses Nushell scripts)
  • Git

Development Setup

  1. Fork the repository
  2. Clone your fork: git clone https://repo.jesusperez.pro/jesus/secretumvault.git
  3. Add upstream: git remote add upstream https://repo.jesusperez.pro/jesus/secretumvault.git
  4. Create a branch: git checkout -b feature/your-feature

Development Workflow

Before You Code

  • Check existing issues and pull requests to avoid duplication
  • Create an issue to discuss major changes before implementing
  • Assign yourself to let others know you're working on it

Code Standards

Rust

  • Run cargo fmt --all before committing
  • All code must pass cargo clippy -- -D warnings
  • Write tests for new functionality
  • Maintain 100% documentation coverage for public APIs

Nushell

  • Validate scripts with nu --ide-check 100 script.nu
  • Follow consistent naming conventions
  • Use type hints where applicable

Nickel

  • Type check schemas with nickel typecheck
  • Document schema fields with comments
  • Test schema validation

Commit Guidelines

  • Write clear, descriptive commit messages
  • Reference issues with Fixes #123 or Related to #123
  • Keep commits focused on a single concern
  • Use imperative mood: "Add feature" not "Added feature"

Testing

All changes must include tests:

# Run all tests
cargo test --workspace

# Run with coverage
cargo llvm-cov --all-features --lcov

# Run locally before pushing
just ci-full

Pull Request Process

  1. Update documentation for any changed functionality
  2. Add tests for new code
  3. Ensure all CI checks pass
  4. Request review from maintainers
  5. Be responsive to feedback and iterate quickly

Review Process

  • Maintainers will review your PR within 3-5 business days
  • Feedback is constructive and meant to improve the code
  • All discussions should be respectful and professional
  • Once approved, maintainers will merge the PR

Reporting Bugs

Found a bug? Please file an issue with:

  • Title: Clear, descriptive title
  • Description: What happened and what you expected
  • Steps to reproduce: Minimal reproducible example
  • Environment: OS, Rust version, etc.
  • Screenshots: If applicable

Suggesting Enhancements

Have an idea? Please file an issue with:

  • Title: Clear feature title
  • Description: What, why, and how
  • Use cases: Real-world scenarios where this would help
  • Alternative approaches: If you've considered any

Documentation

  • Keep README.md up to date
  • Document public APIs with rustdoc comments
  • Add examples for non-obvious functionality
  • Update CHANGELOG.md with your changes

Release Process

Maintainers handle releases following semantic versioning:

  • MAJOR: Breaking changes
  • MINOR: New features (backward compatible)
  • PATCH: Bug fixes

Questions?

  • Check existing documentation and issues
  • Ask in discussions or open an issue
  • Join our community channels

Thank you for contributing!