Contributing to c9watch
February 9, 2026 · View on GitHub
Thanks for your interest in contributing to c9watch! This document provides guidelines and instructions for contributing.
Table of Contents
- Code of Conduct
- How to Contribute
- Development Setup
- Contribution Workflow
- Coding Standards
- Commit Messages
- Pull Request Process
Code of Conduct
- Be respectful and inclusive
- Focus on constructive feedback
- Help create a welcoming environment for all contributors
How to Contribute
Reporting Bugs
If you find a bug, please open an issue with:
- A clear, descriptive title
- Steps to reproduce the issue
- Expected vs actual behavior
- Your environment (macOS version, c9watch version)
- Screenshots if applicable
Suggesting Features
Feature requests are welcome! Please:
- Check if the feature has already been requested
- Explain the use case and why it would be valuable
- Provide examples of how it would work
Contributing Code
We welcome code contributions! Areas where we especially need help:
- Platform support: Windows and Linux ports
- Performance: Optimization of session detection and parsing
- UI improvements: Better visualizations and user experience
- Bug fixes: Check our issues
Development Setup
Prerequisites
- Rust (latest stable)
- Node.js v18 or higher
- Tauri prerequisites for your platform
Initial Setup
# Fork the repository on GitHub, then clone your fork
git clone https://github.com/YOUR_USERNAME/c9watch.git
cd c9watch
# Install dependencies
npm install
# Run in development mode
npm run tauri dev
Project Structure
c9watch/
├── src/ # SvelteKit frontend (TypeScript, Svelte)
│ ├── routes/ # Pages
│ ├── lib/
│ │ ├── components/ # Reusable Svelte components
│ │ ├── stores/ # Reactive state
│ │ └── api.ts # Tauri command wrappers
├── src-tauri/ # Rust backend
│ └── src/
│ ├── lib.rs # Main entry point
│ ├── polling.rs # Session detection loop
│ └── session/ # Session-related logic
Contribution Workflow
1. Fork and Clone
Fork the repository to your GitHub account, then clone your fork.
2. Create a Branch
Always create a feature branch for your work:
# For new features
git checkout -b feature/your-feature-name
# For bug fixes
git checkout -b fix/bug-description
# For documentation
git checkout -b docs/what-you-are-documenting
3. Make Changes
- Write clear, readable code
- Follow existing code style
- Add tests if applicable
- Update documentation if needed
4. Test Your Changes
# Run the app in dev mode
npm run tauri dev
# Build to test production build
npm run tauri build
# Test the built app
open src-tauri/target/release/bundle/macos/c9watch.app
5. Commit Your Changes
See Commit Messages section below.
6. Push and Create PR
# Push to your fork
git push -u origin feature/your-feature-name
Then open a Pull Request on GitHub from your fork to the main repository.
Coding Standards
Rust Code
- Follow Rust API Guidelines
- Run
cargo fmtbefore committing - Run
cargo clippyand fix warnings - Keep functions small and focused
- Add comments for complex logic
# Format code
cd src-tauri && cargo fmt
# Check for issues
cd src-tauri && cargo clippy
TypeScript/Svelte Code
- Use TypeScript for type safety
- Follow existing component structure
- Keep components small and reusable
- Use Svelte 5 runes (
$state,$derived,$effect)
Style
- Use tabs for indentation (project convention)
- Keep lines under 100 characters when reasonable
- Add blank lines to separate logical sections
Commit Messages
We follow Conventional Commits:
<type>: <description>
[optional body]
[optional footer]
Types
feat:- New featurefix:- Bug fixdocs:- Documentation changesrefactor:- Code refactoring (no behavior change)perf:- Performance improvementstest:- Adding or updating testschore:- Build process, dependencies, tooling
Examples
feat: add Windows support for session detection
fix: prevent crash when session file is corrupted
docs: update installation instructions for Linux
refactor: simplify status determination logic
Pull Request Process
Before Submitting
- Code builds successfully (
npm run tauri build) - App runs without errors (
npm run tauri dev) - Code follows project style (run formatters)
- Commit messages follow convention
- Branch is up to date with
main
# Update your branch with latest main
git fetch upstream
git rebase upstream/main
PR Description
Include:
- What - What does this PR do?
- Why - Why is this change needed?
- How - How did you implement it?
- Testing - How did you test it?
- Screenshots - If UI changes, include before/after screenshots
Review Process
- Maintainer will review your PR
- Address any requested changes
- Once approved, maintainer will merge your PR
- Your contribution will be included in the next release!
After Merge
Your branch will be automatically deleted. You can safely delete your local branch:
git checkout main
git branch -d feature/your-feature-name
Getting Help
- Open an issue for bugs or feature requests
- Ask questions in PR comments
- Check existing issues and PRs for similar discussions
Platform-Specific Contributions
macOS (currently supported)
- Test on different macOS versions if possible
- Ensure compatibility with both Intel and Apple Silicon
Linux (in progress - see PR #2)
- Help test and refine Linux support
- Document distribution-specific issues
Windows (in progress - see PR #1)
- Help test and refine Windows support
- Document Windows-specific requirements
License
By contributing, you agree that your contributions will be licensed under the MIT License.