Files
owlen/CONTRIBUTING.md
vikingowl 13af046eff Introduce pre-commit hooks and update contribution guidelines
- Add `.pre-commit-config.yaml` with hooks for formatting, linting, and general file checks.
- Update `CONTRIBUTING.md` to include pre-commit setup instructions and emphasize automated checks during commits.
- Provide detailed steps for installing and running pre-commit hooks.
2025-10-05 02:30:19 +02:00

4.2 KiB

Contributing to Owlen

First off, thank you for considering contributing to Owlen! It's people like you that make Owlen such a great tool.

Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.

Code of Conduct

This project and everyone participating in it is governed by the Owlen Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior.

How Can I Contribute?

Reporting Bugs

This is one of the most helpful ways you can contribute. Before creating a bug report, please check a few things:

  1. Check the troubleshooting guide. Your issue might be a common one with a known solution.
  2. Search the existing issues. It's possible someone has already reported the same bug. If so, add a comment to the existing issue instead of creating a new one.

When you are creating a bug report, please include as many details as possible. Fill out the required template, the information it asks for helps us resolve issues faster.

Suggesting Enhancements

If you have an idea for a new feature or an improvement to an existing one, we'd love to hear about it. Please provide as much context as you can about what you're trying to achieve.

Your First Code Contribution

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

Pull Requests

The process for submitting a pull request is as follows:

  1. Fork the repository and create your branch from main.
  2. Set up pre-commit hooks (see Development Setup above). This will automatically format and lint your code.
  3. Make your changes.
  4. Run the tests.
    • cargo test --all
  5. Commit your changes. The pre-commit hooks will automatically run cargo fmt, cargo check, and cargo clippy. If you need to bypass the hooks (not recommended), use git commit --no-verify.
  6. Add a clear, concise commit message. We follow the Conventional Commits specification.
  7. Push to your fork and submit a pull request to Owlen's main branch.
  8. Include a clear description of the problem and solution. Include the relevant issue number if applicable.

Development Setup

To get started with the codebase, you'll need to have Rust installed. Then, you can clone the repository and build the project:

git clone https://github.com/Owlibou/owlen.git
cd owlen
cargo build

Pre-commit Hooks

We use pre-commit to automatically run formatting and linting checks before each commit. This helps maintain code quality and consistency.

Install pre-commit:

# Arch Linux
sudo pacman -S pre-commit

# Other Linux/macOS
pip install pre-commit

# Verify installation
pre-commit --version

Setup the hooks:

cd owlen
pre-commit install

Once installed, the hooks will automatically run on every commit. You can also run them manually:

# Run on all files
pre-commit run --all-files

# Run on staged files only
pre-commit run

The pre-commit hooks will check:

  • Code formatting (cargo fmt)
  • Compilation (cargo check)
  • Linting (cargo clippy --all-features)
  • General file hygiene (trailing whitespace, EOF newlines, etc.)

Coding Style

  • We use cargo fmt for automated code formatting. Please run it before committing your changes.
  • We use cargo clippy for linting. Your code should be free of any clippy warnings.

Commit Message Conventions

We use Conventional Commits for our commit messages. This allows for automated changelog generation and makes the project history easier to read.

The basic format is:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Types: feat, fix, docs, style, refactor, test, chore, build, ci.

Example:

feat(provider): add support for Gemini Pro

Thank you for your contribution!