The best technical communities feel both rigorous and human. These guidelines are intentionally simple.

1. Share evidence, not certainty theater

Link to the repository, documentation, release, issue, benchmark, or experiment when you can. Separate what you observed from what you infer. If you do not know, say so — uncertainty is useful information.

2. Critique decisions and systems, not people

Strong disagreement is welcome. Contempt is not. Explain the trade-off, failure mode, or missing evidence without making the conversation personal.

3. Protect people and systems

Never post passwords, API keys, private logs, personal data, access tokens, customer records, or unredacted security reports. For a vulnerability, share the minimum public detail and use the project’s responsible disclosure channel.

4. Disclose your relationship

If you maintain, work for, invest in, or are paid by a project you recommend, say so clearly. Promotion is welcome when it is relevant and transparent.

5. Make posts reusable

Good titles describe the decision or problem. Include environment, version, constraints, what you tried, and what outcome would count as success. Search-friendly should mean useful to a future reader — not keyword stuffing.

6. Keep rankings independent

Sponsorship or commercial relationships must never be presented as neutral technical evidence. AtlasRepo scores and community opinions are decision support, not security certification.

Flag content that exposes sensitive data, harasses someone, impersonates a person, or manipulates rankings. Staff will preserve useful technical context while protecting the community.

Thank you for helping make this a place where builders can change their mind without losing face.