Contributing

Thanks for helping improve Infomap. The project is maintainer-led and accepts a small number of external pull requests. This is intentional: Infomap's runtime behavior is regression-sensitive, and changes can be difficult to validate without deep project context.

Issues, discussions, bug reports, reproducible examples, documentation fixes, and small maintenance suggestions are welcome. For code changes, open an issue or discussion first so maintainers can confirm the scope and validation path before review work starts.

Maintainers are most likely to review a pull request when it is:

• discussed with maintainers before implementation
• small, focused, and easy to verify
• limited to documentation, tests, packaging, or clearly bounded fixes
• explicit about what you verified and what you did not

Maintainers usually handle runtime, algorithmic, numerical, determinism, memory, release, and broad cross-surface changes directly. If you are unsure whether a change fits, start with an issue or discussion instead of a pull request.

Before you open an agreed pull request, read:

• BUILD.md for local build and verification commands
• ARCHITECTURE.md for source-of-truth and ownership rules
• AGENTS.md for repo-local maintenance guidance and the verification matrix
• RELEASING.md before you touch release or publishing behavior, and for the Python API deprecation policy before you deprecate or remove public names

Branch from master. Do not push directly to master. Use Conventional Commits for commit messages. Run the smallest sufficient verification from AGENTS.md before requesting review.