Skip to content

Contributing

CodingJeffRoblox edited this page Sep 23, 2026 · 1 revision

Contributing

ByteRescue is open source and welcomes contributions. The full guide lives in CONTRIBUTING.md — this page summarizes it.

Setting up

git clone https://github.com/YOUR_USERNAME/ByteRescue.git
cd ByteRescue
python -m pip install -r requirements.txt
python app.py

A virtual environment is recommended (python -m venv venv, then activate it) before installing dependencies. See Installation for the normal (non-dev) install path.

What's welcome

  • Bug fixes — crashes, error handling, file-detection logic, recovery algorithms, GUI bugs
  • Features — additional file signature support, new analysis tools, recovery capabilities, UI improvements, performance work
  • Documentation — README/wiki improvements, guides, code docs, translations
  • Testing — unit tests, integration tests, edge cases, test infrastructure (see Testing)

Development priorities

Priority Focus
High Crash fixes, stability, error handling, security vulnerabilities, critical bugs
Medium New file signature support, performance, UI enhancements, documentation
Low Nice-to-have features, minor UI polish, experimental features

Current development areas

Enhanced file signature database, improved recovery algorithms, better error handling/user feedback, additional analysis tools, performance optimizations.

Future considerations

Linux and macOS support, advanced carving techniques, RAID recovery support, file system reconstruction, automated recovery workflows.

Submitting a change

  1. Branch: git checkout -b feature/your-feature-name (or fix/your-bug-fix)
  2. Commit your changes with a clear message
  3. Push to your fork and open a Pull Request against main
  4. One PR per feature/fix; describe what changed and why; reference related issues

Code style follows PEP 8; keep functions focused; add docstrings; test manually (including edge cases) before submitting, and never test against a drive holding real data you care about.

Guidelines for specific areas

  • GUI — maintain the dark theme, keep text readable, test at different resolutions, consider keyboard navigation
  • File signatures — test with real files of each type, document the pattern, handle false positives, update Recovery Signatures
  • Recovery algorithms — test across file systems, handle corrupted data gracefully, provide progress feedback, document the algorithm
  • Documentation — clear, concise, accurate, with examples where helpful

Community

Be respectful, collaborative, and professional — see the Code of Conduct. By contributing, you agree your contributions are licensed under the project's MIT License.

Questions? Open an issue or start a discussion.

Clone this wiki locally