Skip to content

Latest commit

 

History

History
74 lines (55 loc) · 2.26 KB

File metadata and controls

74 lines (55 loc) · 2.26 KB

Contributing to Concord

Thanks for your interest in Concord. Any issues, pull requests, and feedback are welcome.

Ground rules

  • Concord is an unofficial Discord client. Using it can violate Discord's Terms of Service. Do not contribute features that automate self-bot behavior, mass actions, or scraping that would put a real user account at risk.
  • Concord is licensed under GPL-3.0-only. By submitting a contribution you agree it will be distributed under the same license.
  • Be kind and concrete. Bug reports and feature proposals are easier to act on when they include a reproduction or a clear use case.

Reporting bugs

Open an issue at https://github.com/chojs23/concord/issues with:

  • OS, terminal emulator, and graphics protocol you expect (Kitty, iTerm2, Sixel, Halfblocks).
  • Concord version
  • Steps to reproduce, expected behavior, actual behavior.
  • Relevant log excerpts. You can enable file logging via the in-app diagnostics popup; redact tokens, passwords, MFA codes, QR tickets, and any raw auth response bodies before sharing logs.

Development setup

You need the Rust stable toolchain. MSRV is 1.85 and the edition is 2024.

git clone https://github.com/chojs23/concord.git
cd concord
cargo build
cargo run

A Nix dev shell with the pinned toolchain and rust-analyzer is available:

nix develop

Cargo is the only build tool. There is no Makefile, Justfile, or workspace root.

Before you push

Run these locally; CI runs the same checks.

cargo fmt --all --check
cargo clippy --all-targets --all-features -- -D warnings
cargo test --all-features

For release-shaped builds:

cargo build --release

Commits and pull requests

  • Use semantic commit subjects: feat:, fix:, refactor:, docs:, chore:, test:. Keep the subject under ~72 characters.
  • Wrap commit-message prose at standard git widths. Put short identifiers in backticks; put multi-line code in indented fenced blocks.
  • Explain non-obvious trade-offs in the body. The "why" matters more than the "what".
  • One logical change per PR is easier to review than a grab bag.
  • Fill in the PR description with: what the change does, why, how you tested it, and screenshots or recordings for UI changes if you can.