secretumvault/CONTRIBUTING.md

130 lines
3.3 KiB
Markdown
Raw Normal View History

# 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](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:
```bash
# 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!