Contributing to ElixirTorrent

Copy Markdown View Source

Thanks for taking a look at this project — contributions are genuinely welcome, whether that's a bug report, a documentation fix, a new BEP, or just a question. This started as a student project and grew from there, so no contribution is too small to be useful, and no question is too basic to ask.

Ways to help

  • Report a bug — open an issue. Include what you expected, what happened, and (if you can) the relevant slice of the log or a minimal reproduction.
  • Suggest an improvement — an issue works fine for this too; it's fine if it's just an idea rather than a fully worked-out proposal.
  • Improve documentation — README clarity, HexDocs @moduledoc/@doc coverage, or the BEP compliance table all count.
  • Send a pull request — for anything beyond a typo fix, opening an issue first is a good way to make sure the approach makes sense before you put time into it.

Found a security vulnerability instead? Please don't open a public issue for that — see SECURITY.md for how to report it privately.

Getting set up

git clone https://github.com/daniboybye/ElixirTorrent.git
cd ElixirTorrent
mix deps.get
mix test

Requires Elixir 1.20+ (see .tool-versions for the exact pinned toolchain used in CI).

Before opening a pull request

The same checks CI runs are available locally, so you can catch issues before pushing:

mix format
mix quality   # compile --warnings-as-errors, dialyzer, credo --all
mix test

A few conventions this codebase follows, worth keeping in mind:

  • Tests are event-driven, not timing-based. Avoid Process.sleep/:timer.sleep in tests — use messages, monitors, socket events, or :sys.get_state barriers instead. Flaky sleep-based tests are worse than no test.
  • Commit messages follow a lowercase Conventional Commits-style prefix, e.g. fix(peer): ..., feat(dht): ..., test: ..., docs: ....
  • New functionality should come with tests; a bug fix is a good opportunity to add a regression test for it.

None of this needs to be perfect before you open a PR — it's fine to ask for help getting there. CI (Build, analyze, and test) has to pass before a PR can merge, and existing pull requests are a good place to see the expected shape of a change.

Code of conduct

Be respectful and assume good faith — that's really the whole policy. Disagreements about code and design are normal and welcome; personal attacks aren't.