130 lines
3.3 KiB
Markdown
130 lines
3.3 KiB
Markdown
# 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!
|