These guidelines are based on the mozilla.org Forum Guidelines, used and modified under a CC BY-SA Unported 3.0+ license. Note that civil community conduct is of the utmost importance, and these guidelines are not intended to be taken as the only bounds on acceptable conduct.
There are a few ground rules for participation in community communication (mailing lists, issues, etc) in the OSVR project. Offenses may result in removal of the conduct from archives, if applicable, and can result in a temporary or permanent ban of the offending member from the community. Please respect these rules, and each other.
No personal attacks. Do not feel compelled to defend your honor in public. Personal attacks and/or harassment of any kind are not tolerated, and have consequences as discussed above.
Community members are busy people, so please pay attention to the topic of your messages, and check that it still relates to the charter of the forum (issue, mailing list, etc) to which you are posting. Off-topic discussion not taken to private email or any place where it is not considered off-topic, by someone who knows they should be taking it elsewhere, may be removed from archives, with patterns of such behavior resulting in more serious consequences as discussed above..
Newcomers may be annoying. They ask the wrong questions, including ones that seem obvious (or whose answers seem easy to find). But lots of valued contributors start out this way, and treating newcomers kindly makes them more likely to turn into the valuable community members we all know and love (and cut some slack when they mess up).
So while you don’t have to humor them or suffer them gladly, and it’s fine to point out when they make mistakes, point newcomers in the right direction in addition to turning them away from the wrong ones, and be kind to them in the process of correcting their transgressions.
It’s tempting to revisit controversial decisions you disagree with, but it’s rarely productive to do so, since it almost always results in the same heated, lengthy, and time/energy draining discussions leading to the same conclusion that was reached in the last round.
Therefore, for issues already raised, discussed, and decided upon, reopen the discussion only if you have significant new information that would reasonably prompt reconsideration of the original decision.
It is almost never appropriate to send the same message to two mailing lists, forums, or newsgroups. Please don’t do it.
These community venues are for discussions about the OSVR software ecosystem and OSVR HDK design. As such, discussions about which operating system is better, or whether one toolkit is better than another, or whether (insert VR entity here) is the root of all evil, are not relevant. There are many forums for discussing such issues on the internet; please have such discussions there instead of in the OSVR community venues.
Spam is a blight upon the face of the net. Nobody likes it. However, it is hard to avoid. Despite our best efforts, you will occasionally see spam on the OSVR mailing lists and newsgroups. If you feel the need to flame the spammer, do not CC the list. Complaining about spam in public increases noise, but not signal. It may make you feel better, but it doesn’t help. (For info on fighting spam effectively, check out spam.abuse.net.)
Do not send binary attachments, including screen shots, and especially including screen shots of textual dialog boxes. Many people read these messages through slow network connections; try to be respectful of them. If you have a large file that you would like to distribute, put it on a Web page and announce the URL instead of attaching it.
Do not quote the entire content of the message to which you are replying. Include only as much as is necessary for context. Remember that if someone wants to read the original message, they can; it is easily accessible. A good rule of thumb is, don’t include more quoted text than new text.
There is always a need for some trimming - either a salutation, a signature, some blank lines or whatever. If you are doing no trimming whatsoever of the quoted text, then you aren’t trimming enough.
Some people like to put reply after the quoted text, some like it the other way around, and still some prefer interspersed style. Debates about which posting style is better have led to many flame wars in the checkered history of the internet. To keep forum discussion friendly, please do interspersion with trimming (see above for trimming rules). For a simple reply, this is equivalent to bottom-posting. So, remove extraneous material, and place your comments in logical order, after the text you are commenting upon.
Keep in mind that not everyone uses mail or news readers that can easily display HTML messages. Consequently, you will reach a larger audience if you post in plain-text. Many people simply ignore HTML messages, because it takes a nontrivial amount of effort to read them.
If you encounter a bug, please take the time to file a report in the appropriate GitHub issues tracker about it. OSVR developers do not all have time to follow all the OSVR-related forums on a regular basis, and if you just post a bug report to a forum or mailing list then it may not reach anyone who can actually do anything about the bug. By reporting the bug through GitHub you ensure that it will receive a higher level of attention, and will be tracked along with other bugs.
Not everyone has time reading all forum postings. To ensure that your message reach the right people at timely manner, identify your subject matter clearly in the subject line. Subjects like "a question" and "OSVR problem" are not very helpful.
Unfortunately, this bears repeating. Find out more about unsubscribing in the Mailing Lists section.
Please do not send test messages to the mailing lists.
devel is not support.OSVR is a large effort with many potential audiences. There are specific channels for "support" requests - see support.osvr.com - that get different kinds of attention than the development discussion media. When deciding whether a message is a support request or suitable for a devel post, err on the side of sending it to support: support will let you know if your question might be better suited to another venue.