Contributing Guide

​

Welcome Contributors!

​

Getting Started

​

Prerequisites

1. A GitHub account
2. Git installed on your machine
3. Development environment set up (see Building from Source)
4. Basic familiarity with Rust and JavaScript

​

Code of Conduct

​

Contribution Workflow

​

1. Fork the Repository

1. Visit github.com/NaturalDevCR/TCP-Streamer
2. Click the Fork button in the top-right corner
3. Clone your fork locally:

git clone https://github.com/YOUR_USERNAME/TCP-Streamer.git
cd TCP-Streamer

​

2. Create a Feature Branch

# For new features
git checkout -b feature/amazing-feature

# For bug fixes
git checkout -b fix/connection-timeout

# For documentation
git checkout -b docs/update-installation

• feature/ - New features or enhancements
• fix/ - Bug fixes
• docs/ - Documentation changes
• refactor/ - Code refactoring
• test/ - Adding or updating tests

​

3. Make Your Changes

# Start development server
npm run tauri dev

# Make changes to the code
# Test your changes thoroughly

• Test on your target platform(s) before submitting
• Keep changes focused on a single feature or fix
• Write clear, self-documenting code
• Add comments for complex logic
• Update documentation if you change behavior

​

4. Format Your Code

# Format Rust code
cd src-tauri
cargo fmt
cd ..

​

5. Run Tests

# Run Rust tests
cargo test --manifest-path=src-tauri/Cargo.toml

​

6. Commit Your Changes

git add .
git commit -m "Add amazing feature"

• Use present tense (“Add feature” not “Added feature”)
• Be descriptive but concise
• Reference issue numbers when applicable: Fix connection timeout (#123)

git commit -m "Add adaptive buffer resizing based on network jitter"
git commit -m "Fix WASAPI loopback stuttering on Windows"
git commit -m "Update README with macOS installation instructions"
git commit -m "Refactor audio pipeline to use lock-free ring buffer"

​

7. Push to Your Fork

git push origin feature/amazing-feature

​

8. Open a Pull Request

1. Go to your fork on GitHub
2. Click Compare & pull request
3. Fill out the PR template with:
   • Description: What does this PR do?
   • Motivation: Why is this change needed?
   • Testing: How did you test it?
   • Screenshots: If UI changes, include before/after screenshots
4. Submit the pull request

• Link related issues using keywords: Closes #123 or Fixes #456
• Keep PRs focused on a single feature/fix
• Respond to review comments promptly
• Be open to feedback and suggestions

​

Types of Contributions

​

Bug Reports

• TCP Streamer version
• Operating system and version
• Steps to reproduce the bug
• Expected behavior
• Actual behavior
• Error messages or logs
• Screenshots if applicable

​

Feature Requests

• The problem you’re trying to solve
• Your proposed solution
• Alternative solutions you’ve considered
• Use cases and benefits

​

Documentation

• Fixing typos or unclear wording
• Adding examples or tutorials
• Updating outdated information
• Translating documentation

​

Code Contributions

• Implementing new features
• Fixing bugs
• Improving performance
• Refactoring code
• Adding tests

​

Development Guidelines

​

Code Style

• Follow the Rust API Guidelines
• Use cargo fmt for formatting
• Use cargo clippy for linting
• Write idiomatic Rust code

• Use modern ES6+ syntax
• Keep functions small and focused
• Use meaningful variable names
• Avoid global variables

​

Architecture Principles

• Frontend (src/): HTML/CSS/JavaScript using Vite
• Backend (src-tauri/): Rust with Tauri framework
• Audio Pipeline: cpal → Ring Buffer → TCP Stream
• State Management: Tauri plugin-store for persistence

​

Testing

• Test your changes manually on your platform
• Test edge cases (e.g., network disconnection, device changes)
• Verify no regressions in existing functionality
• Consider adding unit tests for complex logic

​

Performance Considerations

• Audio streaming is latency-sensitive - avoid blocking operations
• Use lock-free data structures for audio pipeline
• Profile performance-critical code
• Test on low-end hardware when possible

​

Review Process

​

What to Expect

1. Initial Review: Maintainers will review your PR within a few days
2. Feedback: You may receive feedback or change requests
3. Iteration: Address feedback by pushing new commits
4. Approval: Once approved, your PR will be merged
5. Release: Your changes will be included in the next release

​

Review Criteria

• Does the code work as intended?
• Is the code well-structured and maintainable?
• Are there any security concerns?
• Does it follow the project’s architecture?
• Is documentation updated if needed?
• Are there any breaking changes?

​

Getting Help

​

Resources

• Documentation: Read the full documentation
• Issues: Browse existing issues
• Discussions: Ask questions in GitHub Discussions

​

Questions?

1. Check if there’s an existing discussion or issue
2. Start a new discussion in GitHub Discussions
3. Be specific about what you need help with

​

Recognition

​

License