Skip to main content
🤖AI-generated documentation✓ curatedAI Generated
This page was drafted by an AI assistant and may contain inaccuracies. This content has been reviewed by a human curator.
About content generation types
🤖
AI Generated — Page drafted entirely by AI from codebase or prompt instructions.
(e.g., docs generated from codebase analysis)
← this page
✋→🤖
AI Transformatted — Human provided raw material; AI restructured it into a different format.
(e.g., livestream → blog post, meeting notes → docs)
✋
Human Generated — Page written entirely by a human author.
(e.g., hand-written tutorial)
More info about content generation types ↗

Contributing to SkellyCam

We love your input and we need your help! We want to make contributing to this project as easy and transparent as possible, whether it's reporting a bug, discussing the current state of the code, submitting a fix, proposing new features, or becoming a maintainer.

Development with GitHub​

We use GitHub to host code, track issues and feature requests, and accept pull requests.

GitHub Flow​

We use GitHub Flow, so all code changes happen through pull requests:

  1. Fork the repo and create your branch from development.
  2. If you've added code that should be tested, add tests.
  3. If you've changed APIs, update the documentation.
  4. Ensure the test suite passes.
  5. Make sure your code lints (uv run ruff check skellycam/).
  6. Issue that pull request!

Licensing​

Any contributions you make will be under the AGPL Software License. When you submit code changes, your submissions are understood to be under the same AGPL that covers the project.

Reporting Bugs​

We use GitHub Issues to track bugs. Report a bug by opening a new issue.

Great bug reports tend to have:

  • A quick summary and/or background
  • Steps to reproduce (be specific!)
  • Include an uploaded ZIP of the skellycam recording session you ran that produced the issue
  • What you expected would happen
  • What actually happens
  • Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)

Pull Request Guidelines​

  • Any code that comes through a PR should be covered with tests
  • Those tests must pass the GitHub Actions workflow before they may be merged
  • Any UI changes should include a small video of the working application with the change included

A Note on Review Timelines​

We're a small team, and as Nadia Eghbal describes in Working in Public, developer attention is the primary limiting resource in open-source projects. Please be patient with pull request reviews — they can take time, especially when the team is focused on core development work.

A few things that affect review priority:

  • Contributions touching hot or hard loops — the frame capture pipeline, synchronization gate, shared memory, and timestamp logic — receive much higher scrutiny than changes to soft loops (UI, streaming, logging). We don't meant to gatekeep, but a subtle bug in these parts of the code can silently corrupt scientific data and downstream processing pipelines.
  • First-time contributors: consider reaching out on the Discord server before investing significant time. We're happy to discuss approach and scope before you write the code and let you know where your proposed work fits in to our planned development roadmap.
  • Smaller, focused PRs are reviewed faster than large ones. When in doubt, split your work into multiple PRs.

Coding Style​

We use Ruff for linting. Run uv run ruff check skellycam/ to check and uv run ruff check --fix skellycam/ to auto-fix.

See the Development guide for more details on the development workflow.