Sorry, you need to enable JavaScript to visit this website.

We want to keep the 01 communities a great place to participate, but we need your help to keep it that way. While we have specific guidelines for various tools (see below), in general, you should:

Be nice

  • Be courteous and polite to fellow community members.
  • Respect other people: no regional, racial, gender, or other abuse will be tolerated.

Keep it clean

  • Keep the language clean (no swearing).

Keep it legal

  • Make sure that you have the legal right to post your content and are not violating copyright or other laws.
  • All participation and these guidelines are automatically subject to the Terms of Service.

Stay on topic

  • Do not post to the wrong channel or post off-topic discussions.
  • Visit the community page to find the right place to post your question or discussion.

Guideline Violations - 3 Strikes Method

The point of this section is not to find opportunities to punish people, but we do 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.
  • Contact to report abuse or appeal violations (mistakes happen & will be corrected).

Specific Guidelines

We also have some guidelines that are specific to using certain tools or for some community activities. 

IRC Guidelines

  • Keep it clean: Many of us participate from work, so keep the language clean.
  • Don't be a jerk: Treat people with respect and consideration - no regional, racial, gender or other abuse will be tolerated.
  • 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.
  • Don't post chunks: Avoid posting big chunks of text - use pastebin or a similar service to shorten it to a link.
  • Be patient: Folks might not be around when you ask a question, so wait a while for someone to speak before leaving.
  • Don't private message: Ask permission before you send someone a private message (PM). Not everyone likes them. Also, by keeping it in public, others with similar issues can see the solution you were given.
  • More information: This IRC primer for new users and the general IRC guidelines, from freenode, are also useful resources.

Mailing List Guidelines

Remember, when you post to a community mailing list, you are, in effect, asking a large group of people to give you some of their time and attention - to download your message, read it, and potentially reply to it. It is simply polite to make sure your message is relevant to as many of the people receiving the message as possible. Many of the guidelines below stem from this basic principle.

Search First

  • Believe it or not, your question might not be new. Do a thorough search of the mailing list archives to see if it has been answered before.
  • You waste everyone's time if you post repeat questions.

Post on the Right List

  • Visit the project's mailing list page and review the descriptions of each list before deciding where to post your question.

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 only the most recent/relevant messages).

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 highly unwanted in mailing lists because it increases the size of the daily digests and is highly 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. Also, remove any irrelevant text.
  • Use links: Please provide URLs to articles wherever possible. Avoid cutting and pasting whole articles, especially considering the fact that not everyone may be interested.
  • Don't include attached files: Instead of including attached files, please upload your file a server 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.

Subscribers Only

  • 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. Note: 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. 


  • Always reply to the mailing list (not the individual) when answering questions. In many cases, one person will post the question and several others will silently wait to see the answer on the list. This also helps avoid repeat questions because others can search the mailing list to get answers.
  • Do not include more than 10 other recipients in the To: or CC: fields when you post to the mailing list. This triggers the spam filter, and your message will most likely be discarded by the mailing list software.
  • Always group-reply to a message (minding the less than 10 other recipients rule, above). Some of the email recipients might not be subscribed, might have turned off email delivery, or may read list messages with lower priority than messages addressed to them directly. For the same reasons, it is advisable to add relevant people to the recipient list explicitly.

Credit to the Fedora Mailing List Guidelines as a starting point under the Creative Commons Attribution-ShareAlike 3.0 Unported license.

Bug Guidelines

Here are a few guidelines that apply specifically to our bug tracker:

  • Each bug report is for only one issue. If you find several issues, please separate them into several reports.
  • Do a search before you file a bug, and try to avoid filing duplicates by taking a look whether your issue has already been filed before.
  • DO NOT reopen a bug if the same issue is found but its status is CLOSED. Instead, create a new bug report for that issue.
  • Don't start endless debates on topics not directly related to the scope of a specific bug report. We have mailing lists and other places for longer discussions.
  • Avoid quoting complete previous comments by stripping unneeded lines.
  • Avoid answering above the quoted text.
  • Please double check to make sure that the information you are including is public (not confidential), especially in attached log files or screenshots.

Wiki Guidelines

  • Search first: Before creating a new page or making significant contributions to a page, do a quick search to make sure you aren't duplicating existing content on the wiki or other areas of the project website.
  • Contribute: The wiki is a resource for anyone to use. Just keep the content relevant, that is anything related to the project should be appropriate, as long as it meets our other guidelines.
  • Make improvements: If you find a typo or inaccurate information, just fix it.
  • Keep it legal: respect licenses and copyright. Only post content you own or provide attribution for content under a license that permits reuse. As always, our entire Terms of Service also apply to the wiki.
  • Be nice: Keep the language clean (no swearing) and show respect for other contributors.
  • Respect links: Provide redirects when you move content. Many people use the wiki and may have created bookmarks or linked to your content.

The Wiki is Public

Everything in the wiki is public.

Every edit and every new page created goes into the recent changes feed, which means that people will see your edits, even if you haven't yet linked to a page.

Once it's out there, it's public.

  • Technically, administrators can delete things, but the wiki content may be mirrored, has feeds, and is in the Google cache, so deleting something doesn't make it go away.
  • When you delete content from a page, the original content will remain in the history for that page.

Git / Source Guidelines

  • Before writing your patch, browse the git repositories to better understand project coding styles and practices.
  • Some projects prefer to get patches on the mailing list, while others prefer git pull requests. Please spend some time reviewing the mailing list and the git repos before submitting your patch, and when in doubt, ask on the project mailing or in the IRC channel for details about preferred patch submission processes.
  • Unless otherwise specified by an individual project, projects use the signed-off-by language and process, used by the Linux kernel, to give us a clear chain of trust for every patch received. Please carefully read our Signed-off-by Process documentation before contributing to projects.
  • Don't forget to set your author info. We'll need to reject patches / pull requests that show the author as something like <root@localhost.localdomain> or similar. For more details visit the Github user setup page and the Git Reference Commit section.
  • If you are new to git or github, you might find these resources useful: github help files and Git cheat sheets.