Community Guidelines — Remote Valley OS
How we work together, communicate, and build.
These guidelines supplement the Code of Conduct. They describe how we collaborate day-to-day — in issues, pull requests, discussions, and community calls.
Communication Norms
Be specific
Say what you mean. Provide context. Include screenshots, logs, or code snippets when describing a problem.
Good: "The extruder temperature sensor reads 15°C higher than the thermocouple in testing.
Here is the wiring diagram and the raw serial output."
Not good: "The extruder temp is wrong."
Assume good faith
Most people are trying to help. If a comment seems harsh or critical, re-read it with generous intent before responding. Ask clarifying questions before assuming bad intent.
Disagree constructively
Disagreement is healthy. Frame it around the idea, not the person.
Good: "I think a gravity-fed water intake would be more reliable here because it removes the pump failure point."
Not good: "This pump design is wrong."
Default to public
Keep conversations in public GitHub issues, discussions, and pull requests unless there is a specific reason for privacy (personal info, security, Code of Conduct reports). Public discussions help everyone learn and let future contributors find answers.
Use inclusive language
- Avoid jargon, acronyms, and insider references when possible
- If you must use a technical term, explain it
- Remember that English may not be everyone’s first language
- Be patient with non-native speakers — content and grammar matter less than ideas
How We Use GitHub
Issues are for work
- Bug reports, feature requests, and specific tasks
- Each issue should describe one thing clearly
- Use labels to categorize:
bug,enhancement,good-first-issue,help-wanted,documentation,question
Discussions are for conversation
- General questions, ideas, brainstorming, community introductions
- “I want to contribute but I don’t know where to start” → Discussions
- “Should we redesign the sensor ingestion pipeline?” → Discussions (then converted to an RFC issue)
Pull requests are for proposed changes
- Always link to a related issue when possible
- Keep PRs focused on one change
- Large changes should be broken into multiple PRs
Decision-Making Norms
Seek consensus, not speed
Most decisions do not need to be made today. Give people time to respond. A 48-hour minimum for commenting on significant decisions is standard.
Lazy consensus
If you open a proposal and no one objects within the comment period, it is assumed accepted. You do not need explicit approval for everything. But if someone does object, stop and discuss rather than pushing through.
Escalate when stuck
If a discussion has been going in circles for more than a week, tag a maintainer to facilitate. Sometimes an outside perspective helps.
Community Roles (Informal)
| Role | What It Means |
|---|---|
| Visitor | Reading, exploring, learning. No participation expected. |
| Lurker | Following discussions, maybe upvoting. Valuable — lurkers become contributors. |
| Commenter | Asking questions, suggesting ideas, helping others. |
| Contributor | Submitting pull requests, writing documentation, translating. |
| Reviewer | Reviewing pull requests, providing technical feedback. |
| Mentor | Helping new contributors get started, answering beginner questions. |
| Maintainer | Merging PRs, triaging issues, guiding module direction. |
You can move between roles freely. There is no promotion ceremony. You grow into a role by doing the work.
Community Spaces
| Space | Purpose |
|---|---|
| GitHub Issues | Task tracking, bug reports, feature requests |
| GitHub Discussions | Community conversation, Q&A, ideas |
| GitHub Pull Requests | Code and documentation review |
| Community calls (monthly) | Live video meetup, demos, Q&A |
| (Future) chat server | Real-time community conversation |
Giving and Receiving Feedback
Giving feedback
- Start with what you like
- Be specific about what could improve
- Explain why — the reasoning matters more than the opinion
- Offer alternatives, not just criticism
Receiving feedback
- Listen to understand, not to defend
- Ask clarifying questions
- Thank the person for their time and attention
- Take time to process before responding if you feel defensive
Recognition Norms
- Every merged pull request earns a place in the contributors list
- Significant contributions (new module, major redesign, field adaptation) earn co-authorship on the relevant documentation
- Monthly community calls highlight contributor work
- Maintainers are listed on the organization page and module READMEs
A Note on Pace
This is a volunteer community (except for paid residency positions). People contribute when they have time and energy. Do not expect same-day responses. Do not pressure maintainers. If something is urgent, say why — and be understanding if it is still not prioritized.
A Note on Scope
Remote Valley OS has a specific mission: build open-source infrastructure for remote communities. Not every good idea belongs here. If your idea does not fit the mission, that is not a rejection of you or your idea. It might belong in a different project. Fork away.
These guidelines are a living document. Propose changes via pull request or discussion.