The links below show a few channels for you to participate in the Zephyr Project.
How to Contribute
Follow Zephyr Project updates on Github.
The Zephyr Project community encompasses a number of smaller communities, each with its own focus, needs, and methods for communicating.
The Zephyr Project developer community consists of developers from member organizations and the general community who participate in the development of software within the Zephyr Project.
The Zephyr Project member community consists of the member organizations and their representatives. Each member organization provides an administrative representative to the project’s Governing Board, and a technical representative to the Technical Steering Committee, or TSC. You can find more information on the About page. Members meet periodically over conference calls, and face-to-face annually at one of the Linux Foundation’s events.
Members contribute and discuss ideas, submit bugs and bug fixes, provide training, and help those who need it through the community’s forums such as mailing lists, or IRC channels. Anyone can join the developer community, but only member organizations can currently provide members to the project’s leadership, which includes the Chief Architect, a hierarchy of Maintainers, and member representatives on the Technical Steering Committee.
The Zephyr Project user community includes everyone working with the project to build interesting things. If this means you, welcome to the Zephyr community! If not, we would be glad to welcome you.
Overview and General Guidelines
- Be nice: Be courteous and polite to fellow members of the list.
- Respect other people: No regional, racial, gender or other abuse will be tolerated.
- Keep it clean: Keep the language clean (no swearing)
- Be helpful: Be patient with new people and be willing to jump in to answer questions.
- Stay calm: The written word is always subject to interpretation, so give people the benefit of the doubt and try not to let emotions get out of control.
- Keep it legal: Make sure that you have the legal right to post your content and are not violating copyright or other laws.
Read Before Contributing
IMPORTANT: Before you contribute, look through the mailing list archives, bug lists, and documentation first, to see if your question has already been answered. You will get a better response from people if you have already done your due diligence to find obvious or partial answers.
Mailing List Guidelines
Keep it short
Remember that thousands of copies of your message will exist in mailboxes:
- Keep your messages as short as possible.
- Avoid including log output (select only the most relevant lines, or place the log on a website or in a pastebin instead)
- Don’t excessively quote previous messages in the thread (trim the quoted text down to the most recent/relevant messages only).
Use proper posting style
- No HTML or Rich Text: Set your mailer to send only plain text messages to avoid getting caught in our spam filters.
- Do not top post: Top posting is replying to a message on “top” of the quoted text of the previous correspondence. This is unwanted in mailing lists because it increases the size of the daily digests and is confusing and incoherent. By default, most email clients top post. Please, remove the irrelevant part of the previous communication (in case of more than a single correspondence) and use bottom, interleaved posting
- Using interleaved posting: Bottom, interleaved posting is replying to the relevant parts of the previous correspondence just below the block(s) of sentences. For a comment to another block of sentences of the same quoted text, you should move below that relevant block again. Do not reply below the whole of the quoted text. Remove any irrelevant text.
- Use links: Please provide summaries and URLs to articles wherever possible. Avoid cutting and pasting whole articles especially considering all may not be interested.
- Don’t include attached files: Upload your file to this wiki or another website and post a link to the file from your email message.
Do not hijack threads
Post new questions or new topics as new threads (new email message). Please do not reply to a random thread with a new question or start an unrelated topic of conversation in an existing thread. This creates confusion and makes it much less likely that you will get a response.
Do not cross post
Avoid posting to multiple lists simultaneously. Pick a mailing list that is most suitable for your post and just use that. CC’ing multiple lists should be avoided.
Only subscribers can post to our mailing lists. If you would like to contribute to our mailing lists, we think it is only fair that you be a subscriber. Please note that if you want to participate only occasionally, you can subscribe to a list and set your email options to digest or no mail and read the web archives when you want to catch up.
Mailing list guidelines by Shakthi Kannan (PDF): Great guideline summary and examples of posting styles.
Bug Posting Guidelines
We like communications to run smoothly. To that end here are some guidelines for participating in our bug tracking system.
- Be patient with others: Sometimes people post imperfect bug reports. In case of missing information, kindly tell reporters how to provide it, and/or suggest what they can do to improve the bug report.
- Stay on topic: Don’t start endless debates on topics not directly related to the scope of a specific bug report.
- Use proper quoting practices: Avoid quoting complete previous comments by stripping unneeded lines, and avoid answering above the quoted text.
- Don’t abuse your privileges: Submitters have permission to edit their bugs. If you abuse this privilege – for example, by reopening a bug that the maintainers have closed – your privileges will be revoked.
What to do if you find a bug
- Search first: Try to avoid filing duplicates by searching to see whether your issue has already been filed.
- Ask: You can ask on our mailing lists to see if anyone has seen this issue before to gather more details or see if someone has a workaround.
- Submit a bug report: Give us as many details as possible about what happened and how your issue can be reproduced.
- Track our progress: Get feedback from the development community and track resolution status.
- Provide a fix: If you know of a fix and/or workaround, please let us know.
Guideline Violations - 3 Strikes Method
We need a fair way to deal with people who are making our community an unpleasant place.
- First occurrence: Public reminder that the behavior is inappropriate according to our guidelines.
- Second occurrence: Private message warning the user that any additional violations will result in removal from the community.
- Third occurrence: Depending on the violation, may include account deletion or banning.
- Obvious spammers are banned on first occurrence. This is necessary to keep the community free of spam.
- Violations are forgiven after 6 months of good behavior.
- Minor formatting/style infractions will be dealt with through education, not the 3 strikes process.
- Extreme violations of a threatening, abusive, destructive or illegal nature will be addressed immediately and are not subject to 3 strikes.
Adapted from the Yocto Project Community Guidelines