Skip to content

discord-rules.md

Latest commit

 

History

History
61 lines (45 loc) · 2.85 KB

discord-rules.md

File metadata and controls

61 lines (45 loc) · 2.85 KB
Raw

Discord Rules

General Rules

  1. This community works together to build an Open Source BMC firmware. It's a community expectation that you will provide access to your code in the course of discussions. We are unable to build together if you are unable to share your code. The community is not a substitute for a support contract.

  2. OpenBMC community members are volunteering their time to answer your questions. Please keep this in mind if you are waiting for a response.

  3. All support questions must be asked in public channels. Do not send uninvited private messages to other community members. Private requests for help place an unfair burden of expectation on people volunteering their time. Further, others in the community cannot help if they cannot see the question.

  4. Don't post the same question in multiple channels. Doing so fragments the conversation. If you're unsure of which channel to use, ask your question in #general and we may redirect you elsewhere.

  5. Reflect on whether your standing in the community is appropriate for the help you are requesting. If you are new to the community, you will likely have the most success by asking detailed, specific questions about detailed, specific problems. Vague questions by unfamiliar people often go unanswered.

  6. Do not discuss undisclosed bugs that may have a security impact in Discord. Instead, email openbmc-security@lists.ozlabs.org and follow the documented directions.

Channel Specific Rules

#code-reviews

  1. All code review requests must only be posted to the #code-reviews channel.

  2. Review requests on Discord must wait at least 48 hours from submission (or subsequent revisions) and should only be sent on working days1. Maintainers and reviewers are expected to work primarily in Gerrit; availability on Discord is a courtesy. Avoid unnecessary noise to others.

  3. An exception to (1) and (2) is for active investigation and resolution of issues already being discussed. For example, "I just uploaded a fix for this problem at ..." is a productive communication. If you feel your work is "critical" for unblocking others, such as due to a widespread regression, make sure you already have buy-in from maintainers that it is indeed a critical problem, by discussing the issue before posting code. Your individual desire to merge code doesn't make it critical.

#jobs

  1. All jobs related posts (including looking for work) must only be posted to the #jobs channel.

Footnotes

  1. Be mindful that maintainers are in various countries around the world. We don't expect you to know everyone's holiday schedule, but understand you're not likely to get a response if the person you mentioned is on a holiday. ↩