Skip to content

Developer Etiquette Guidelines

Last Updated - June 6th, 2025

Introduction

The ReX Engine Project relies on its developers and contributors to maintain a respectful, focused, and non-disruptive environment. This etiquette guide outlines expectations for behavior and collaboration to ensure a productive and inclusive development process.

Our shared goal is to build and improve the engine while fostering a space where all contributors feel valued, heard, and empowered to participate. If you ever feel that your ideas or proposals are being overlooked, it may be due to a misunderstanding or a misalignment with the guidelines described in this document. Clear communication and adherence to these expectations help ensure that everyone’s voice is fairly considered.

1. Be Respectful

  • Treat all contributors with kindness, patience, and professionalism.
  • Avoid sarcasm, personal attacks, or inflammatory remarks —- especially during technical disagreements.
  • Respect different skill levels, experiences, and backgrounds. Everyone is here to learn and contribute.
  • Assume good intentions, and approach disagreements as opportunities to collaborate —- not compete.
Examples of disrespectful behavior include

  • Dismissing others’ ideas without discussion:

    “You’re not listening—this just needs to be replaced.”

  • Speaking in a condescending or hostile tone:

    “This is probably the dumbest thing I’ve heard.”

  • Overtalking or dominating discussions:

    Ignoring feedback, constantly steering conversation back to your own viewpoint, or not giving others a chance to speak.

  • Mocking or belittling others’ efforts:

    Criticizing code, ideas, or questions in a way that discourages future contributions.

  • Refusing to collaborate or compromise:

    Rejecting changes simply because they aren’t your own, or disregarding the community's or project leadership's consensus.

2. Communicate Clearly

  • Use clear, concise language when writing comments, discord messages, commit messages, issues, or proposals.
  • When making suggestions or raising concerns, explain your reasoning and provide helpful context.
  • When proposing a solution or idea ensure you are following the suggestions in Creating A Proposal
  • Ask questions when something isn’t clear—don’t assume everyone has the same understanding.
  • Avoid passive-aggressive remarks or vague criticism. Be direct, but respectful.
Examples of unacceptable behavior and tips for improvement

  • Vague or unhelpful feedback:

    “This is wrong.” → Instead, explain why it’s wrong and how it could be improved.

  • Unexplained decisions in pull requests:

    Making large changes without a description or justification makes it hard for others to understand the intent.

  • Using overly technical jargon without explanation:

    This can alienate newer contributors. If you use advanced concepts, try to link documentation or explain briefly.

  • Letting frustration show in comments:

    Venting in code reviews or issue threads creates a hostile environment.

  • Summarize problems and solutions clearly.
  • Use bullet points or code snippets where appropriate.
  • Assume others are reading without full context—provide it proactively.

3. Stay On Topic

  • Keep conversations focused on the subject at hand, especially in pull requests, issues, and design discussions.
  • Avoid derailing threads with unrelated ideas, personal side-conversations, or off-topic commentary.
  • If a discussion naturally leads to a new subject, create a separate issue or thread to continue it.
  • If discussing ideas in a general chat, it’s recommended to create a dedicated discussion thread for the topic.

Why this matters:

  • Staying on topic keeps discussions productive and easier to follow.
  • It reduces noise and confusion, especially for new contributors trying to catch up.
  • It helps maintain a clear project history and rationale for changes.
Examples of going off-topic and tips to stay on track
  • Introducing a new feature idea in the middle of a bug report discussion.
  • Debating unrelated architectural choices during a small bug fix PR.
  • Turning technical threads into personal chats or rants.
  • If you or another member realizes your comment is off-topic, acknowledge it and move it to the appropriate place.
  • Use threads or forum-style replies to isolate tangents if necessary.
  • Don’t be afraid to politely redirect the conversation if it’s drifting.

4. Use Proper Channels

  • Use the appropriate platform for the type of communication:

    • GitHub Issues – for bug reports, feature proposals, and technical discussions that need tracking.
    • Pull Requests – for code contributions and change reviews.
    • Discord Forums – for longer-form design discussions and feedback on individual topics.
    • Discord Chat – for quick questions, casual conversation, and coordination.

  • Avoid making important decisions in private messages or informal chats—use public channels so others can follow and participate.

  • If a conversation in chat becomes in-depth or long-term, move it to a Discord forum post or another official discussion space.
  • Keep general channels clear of deep technical debates—create threads to contain and organize complex discussions.

Why this matters:

  • Using the right channels ensures that information is visible, organized, and easy to reference later.
  • It makes onboarding easier for new contributors trying to understand past decisions.
  • It avoids losing important discussions in ephemeral chat history.
Examples of poor channel usage and related bet practices
  • Making a design decision in DMs and not documenting it publicly.
  • Posting lengthy PR feedback in Discord instead of in the pull request.
  • Starting a heated debate about a feature in a casual general chat channel.
  • Default to transparency -- if it affects the project, make it public.
  • Link between chat and GitHub where necessary for continuity.
  • Use threads, tags, and titles to organize discussions clearly.

5. Respect the Review Process

  • Be patient when waiting for reviews; everyone has different time commitments, and the process itself takes time.
  • Project leadership has the responsibility to foster growth and make decisions for the betterment of the project and the community. If your idea isn't accepted or existing work needs to be changed, replaced, or removed to support that goal, please remain respectful of the decisions made and work with leadership to contribute your ideas in other ways.

Change is a good thing!

Change is a natural and necessary part of the development process. It shouldn't be dismissed or fought against to save previous work. Instead it should be used as a tool to drive the project forward while aligning with Redot's values.

  • When performing reviews, be constructive: point out issues clearly and provide explanations and alternative solutions. Don't use the review process to flaunt ego, or make condecending remarks.
  • Follow the review procedures when conducting reviews. Don’t rely solely on personal bias or preferred ways of working.
  • Don’t start implementation of an idea or make significant changes to a system before writing a proposal and getting approval.
  • Don’t merge large or potentially disruptive changes without review and approval from project leadership.

6. Commit Responsibly

  • Follow the project's commit message guidelines and code style.
  • Ensure you are commiting to the appropriate branches as discribed above.
  • Use feature branches and pull requests for collaborative work and review.

7. Seek Consensus

  • Proposals that impact the project's direction or structure should go through discussion and review.
  • Don't push major rewrites or removals without justification.
  • “Working first, then refining” is preferred. Make your progress public even if it's just on a fork of the repo you are targeting.

Progress Transparency

Holding onto changes localy without pushing commits to forks as they happen holds up the development process. If you are working on a project which requires long running developmet or multiple systems working togather to implement pushing these commits as they happen to a publicly reviewwable location is required.

8. Help Others

  • Take time to assist new contributors when you can.
  • Share context, link to documentation, and explain reasoning behind decisions.
  • Mentorship strengthens the project and community.

9. Own Your Mistakes

  • If you break something or realize you made a poor decision, acknowledge it and help fix it.
  • Blame is not useful—solutions and learning are.

10. Be a Good Steward

  • Remember that every contributor represents the project.
  • Encourage a culture of quality, curiosity, and care.
  • Help create an environment that you’d want to contribute to.