Lynkr Code of Conduct

Why this exists

Lynkr is infrastructure people trust with their agent traffic and their money. That trust extends to the community: contributors should be able to file an issue, review a PR, or disagree about routing design without being demeaned, dismissed, or driven off. This document says what we expect, what we don't tolerate, and exactly what happens when someone reports a problem.

We'd rather have a slower answer in an issue thread than a fast one that makes someone feel stupid for asking.

Who and where this covers

This code applies to everyone participating in the Lynkr project — maintainers, contributors, and users — in every project space:

• The GitHub repository: issues, pull requests, discussions, commit messages, and code review comments
• Any project chat, forum, or mailing list
• Social media posts made in connection with the project (e.g., replying to someone's question about Lynkr, discussing a contributor's work)
• Conferences, meetups, and calls where you are representing or discussing Lynkr

It protects everyone, and we name explicitly the characteristics that are most often targeted: age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, religion (or lack of it), and sexual identity and orientation. Experience level is on that list deliberately: this is a technical project, and newcomer-hostility is the failure mode technical projects actually have.

What we expect

• Assume competence, explain context. "This breaks session pinning — here's why that matters" teaches; "did you even read the code?" doesn't.
• Review the code, not the person. Critique in a PR should be specific, actionable, and about the change.
• Welcome imperfect first contributions. A rough PR with a good idea is a gift, not a burden. Say what's good before what's wrong.
• Disagree with receipts. Routing design, benchmarks, and provider quirks are debated with evidence, not volume or seniority.
• Give credit. If an issue, comment, or upstream project shaped your change, say so.
• Accept "no" gracefully. Maintainers will decline changes; contributors may decline suggestions. Neither is an insult.

What we don't tolerate

Concrete examples, because vague codes protect no one:

• Insults, put-downs, or name-calling — including "polite" versions like feigned confusion at someone's question or RTFM-style responses
• Comments that demean anyone based on the characteristics listed above, including "jokes" and stereotypes
• Sexualized language, imagery, or unwelcome sexual attention in any project space
• Harassment: sustained unwanted contact, dogpiling on a contributor, following someone across threads to continue an argument they've exited
• Publishing someone's private information (address, employer, legal name, contact details) without explicit permission
• Gatekeeping: telling someone they're not qualified to participate, use the project, or hold an opinion
• Retaliation against anyone who reports a violation in good faith, or weaponizing this code with knowingly false reports
• Sustained disruption: derailing threads, sealioning, reopening settled decisions without new information

Not violations: rejecting a PR, direct technical criticism of a change, enforcing project scope, or asking someone to take an off-topic discussion elsewhere.

How to report

Email hello@lynkrhq.com with the subject line "Conduct". Include what happened, where (links help), when, and who was involved. Screenshots are welcome; deleted comments are still violations.

• You do not have to be the target to report — witnesses are encouraged to.
• If you are uncomfortable reporting under your name, you may use an alias email account; reports are judged on their evidence, not the reporter's identity.
• If your report concerns the maintainer, we acknowledge the structural problem honestly: Lynkr currently has a single maintainer, so there is no independent chain. For behavior in GitHub-hosted spaces (issues, PRs, discussions, review comments), report it to GitHub via GitHub's Report Abuse process, which the maintainer cannot influence. For behavior elsewhere, report it to that venue's own process — the event's organizers, or the platform's trust and safety channel — all of which are likewise outside the maintainer's control. We name this gap rather than paper over it: until the maintainer team grows, there is no single independent contact for non-GitHub incidents, and this section will be replaced with a named second contact as soon as one exists.

What happens after you report:

1. Acknowledgment within 48 hours that the report was received.
2. Review: the maintainer reads the material, gathers context, and — where it can be done without exposing the reporter — hears from the person reported.
3. Decision within 14 days, communicated to the reporter and the person reported. If it takes longer, you'll be told why and given a new date.
4. Follow-up: for upheld reports, the maintainer checks in with the reporter after roughly one month to confirm the behavior actually stopped. Resolution on paper is not resolution.

Reports are kept confidential. Details are shared only as needed to investigate and act.

Consequences

Proportional to impact and pattern, at the maintainer's judgment:

1. Correction — a private (or, for public harm, public) explanation of why the behavior violated this code, with an expectation it stops.
2. Warning — formal notice that continued behavior means removal, possibly with a cooling-off period away from project spaces.
3. Temporary ban — a defined period of no participation in any project space, including PRs, issues, and review.
4. Permanent ban — for severe violations (threats, harassment campaigns, doxxing) or repeated violations after warning. Severe cases skip the ladder.

Consequences apply to everyone, including the maintainer's collaborators, sponsors, and heaviest contributors. Code quality does not buy conduct exemptions.

Keeping this honest

This document is reviewed every six months (or after any enforcement action, whichever comes first) and the revision date below is updated even when nothing changes, so you can tell it's alive. Substantive changes are made in public PRs like any other change to the project.

This code was written for Lynkr following Project Include's guidance, with structural conventions from the Contributor Covenant community. It is not copy-pasted boilerplate; if part of it doesn't fit how this community actually behaves, open an issue and say so.

Last reviewed: 2026-08-26