Community safety
How to use a developer community chat safely
Developer chat can make open-source work feel less isolating. It is safest when people keep discussions practical, avoid sensitive data, and treat anonymous messages and external offers with appropriate caution.
Use chat for practical, public-safe questions
Community chat works well for asking how to approach a public issue, sharing a small contributor lesson, celebrating a completed documentation improvement, or discussing a score card at a high level. Keep the question narrow enough that another person can answer without needing credentials, private data, or background they cannot safely access.
The WelcomeScore Dev Lounge is temporary and anonymous, not private messaging. A temporary handle does not verify anyone’s identity, project ownership, skill, intent, or reliability.
Keep discussion respectful and useful
Focus feedback on code, documentation, product behavior, and ideas rather than people. Avoid harassment, spam, deceptive links, impersonation, dogpiling, and repeated pressure for a response. If you reply to a message, quote only the context needed to keep the thread understandable.
If you encounter harmful, fraudulent, or policy-violating content, do not amplify it in public. Preserve the minimum useful context and follow the reporting process in the Dev Lounge Policy or Code of Conduct. For a security concern, use the project’s private security route rather than a chat message.
Know the boundary of the feature
Community chat can encourage learning, but it is not customer support, emergency response, legal advice, financial advice, employment advice, a marketplace, or an escrow service. If you need help beyond a practical public question, use an appropriate verified channel.
The safest contribution culture is one where people can ask basic questions without fear, while everyone protects privacy, treats claims cautiously, and respects boundaries.
About this guide
Written by ETHIOR Editorial for contributors and maintainers. This guide explains practical product and repository practices; it is not legal, security, employment, or financial advice. Review the project’s How It Works, Privacy Policy, and Terms & Conditions for product boundaries.
Put the ideas into practice
Run a fresh public GitHub audit and use the visible contributor signals as a starting point—not as a certification of project quality or safety.
Check a repository