TRX is a volunteer, maintainer-led open source project. We're happy to have you here.
Our number one enemy is exhaustion. If discussion drains maintainers more than it helps the project, everyone loses. So we keep communication clean, constructive, and low-friction. There's no room for prolonged negativity, entitlement, or argument-as-a-hobby.
- Curious, practical, kind
- Clear reports, clear proposals
- Disagreement expressed as "here's a better idea"
- Solutions over speeches
You don't need to be an expert, but you do need to be respectful and actionable.
When you want change, write it as a proposal.
Good patterns:
- "It would be great if [specific change], because [reason]".
- "Current behavior: X. Expected behavior: Y. Evidence: Z."
- "Comparison: Original game does [behavior]. TRX does [behavior]."
- "Minimal reproduction case: [shortest possible steps to trigger issue]."
- "After reading [documentation page/section], [specific information] remains unclear."
- "Technical observation: [system/component] appears to ignore [condition/input]."
- "Tested on: [version], [platform], [configuration]. Issue: [description]."
If you can't describe the change clearly, it's not ready to be requested.
Contributions are evaluated, not adopted automatically. Submitting research, proposals, or patches does not guarantee they will be merged in their current form, or at all. Maintainers may modify, defer, or decline contributions to keep the project aligned with its goals and plans.
These are exhaustion-generators. They will be moderated quickly.
- Drive-by bug reports (no steps, no version, no logs, “crashes sometimes”); reports outside bug channels
- Complaints without a concrete proposal
- Catastrophizing ("this ruins the game", "this breaks everything") instead of specifics
- Re-litigating decisions after maintainers say it's decided
- "Truth voice" posting: presenting personal preference as objective fact
- Purity tests and vision wars ("real TR is X", "this feels like it drifts from the original vision", etc.)
- Mislabeling TRX as “just a mod” or otherwise misrepresenting what the project is (TRX is a standalone, reverse engineered, build-from-source engine project).
- Pressure tactics: guilt, demands, timelines, "you must", "you owe", "everyone agrees", "I think it is very important"
TRX is maintainer-led. Maintainers have final say on:
- Project vision and scope
- Features and defaults
- UI/UX and discoverability
- What gets accepted, declined, closed, or locked
You're welcome to suggest. Maintainers decide. If a decision is made, continuing to argue it is not "discussion", it's drain.
To protect the project, maintainers may:
- Ask for a proposal format
- Close issues that aren't actionable
- Lock threads that turn circular or hostile
- Remove disruptive participants from project spaces
We don't want to do this. We will do this.
Instant hard no:
- Harassment or personal attacks
- Discrimination
- Threats or intimidation
Totally fine. Choose a productive path:
- Propose an alternative clearly
- Adjust settings to your taste
- Contribute a patch
- Fork the project
- Go play the OGs, Remasters, or something else altogether
What's not fine is trying to force agreement through volume, repetition, or hostility.
Push hard enough against the current, and even the river will stop trying to pull you along.
When you consistently create friction rather than progress, you will lose your seat at the table. We're building something we care about, and we want the community (and ourselves) to feel good to be in.