Code of Conduct

THIS IS AN UNDERGOING text

Cf https://openhatch.org/wiki/Project_codes_of_conduct

Values overview

This Code of Conduct presents a vision of the shared values and thinking in the VideoLAN community.

In short:

• Be considerate and respectful
• Be collaborative
• Be pragmatic and concise
• Ask if you don't know, share if you know
• Be inclusive
• Be patient

Be considerate and respectful

VideoLAN has millions of users and hundreds of contributors. What you do and contribute will impact the life of others. Think about your actions.

There is absolutely no excuse for personal attacks, racism, sexism or any other form of discrimination based on religion, politics, Linux distribution, Operating System or else.
Respect everyone, no matter what is their level of implication in VideoLAN.

In a disagreement, in the first instance assume that people mean well. A community where people feel comfortable is a productive one.

Means of communications

Valid for all means of communications:

• Do not use foul language, and absolutely NO insults will be tolerated.
• Do not to flame or troll; it is not funny anymore. And, you won't ever reach sam troll level.
• Use common sense all the time.

Mailing lists

When using the VideoLAN mailing lists, please follow these rules:

• The mailing lists exist to foster the development and use of VideoLAN. Non-constructive or off-topic messages, along with other abuses, are not welcome.
• Do not send spam.
• Send all of your e-mails in English. Only use other languages on mailing lists where that is explicitly allowed (e.g. French on debian-user-french).
• Make sure that you are using the proper list. In particular, don't send user-related questions to developer-related mailing lists.
• Wrap your lines at 80 characters or less for ordinary discussion. Lines longer than 80 characters are acceptable for computer-generated output (e.g., ls -l).
• Do not top-post, unless it makes sense.
• Never send your messages in HTML-only; use plain text instead.
• Avoid sending large attachments. Attachments over 65k are usually moderated.
• Do not send automated "out-of-office" or "vacation" messages.
• Do not send "test" messages to determine whether your mail client is working. We have a test mailing list for that.
• Do not send subscription or unsubscription requests to the list address itself; use the respective -request address instead.
• Do not quote messages that were sent to you by other people in private mail, unless agreed beforehand.
• When replying to messages on the mailing list, do not send a carbon copy (CC) to the original poster unless they explicitly request to be copied.
• If you send messages to lists to which you are not subscribed, always note that fact in the body of your message.
• If you want to explain to someone how to use a mailing list, please do it privately.

IRC

When using the VideoLAN IRC channels, please follow these rules:

• Speak in English.
• Never send your messages in colors; use plain text instead.
• Do not send spam links.
• Do not send "test" messages to determine whether your IRC client is working. We have a #test channel for that.
• If you want to explain to someone how to use IRC, do it privately.
• Do not quote messages that were sent to you by other people in private query, unless agreed beforehand.

Forum

• Do not send spam.
• Do not bump a topic several times per day.
• Do not cross-post your question across sub-forums.
• Do not edit too often your past posts.

Disciplinary action and resolution

Disciplinary Actions for direct CoC violations

The following disciplinary actions may or may not be enforced when a direct CoC violation is reported.

NB: Before applying any of those following disciplinary policies, the VideoLAN team will try to discuss the problem with the offender in order to solve it in a more peaceful way. However, it is possible for the team to apply the penalty without further discussions in severe CoC violations.

IRC

• 24 hours ban from the IRC channel.
• Every third violation, the developer will have a 7 days ban.

Trac

• 24 hours ban from trac.
• Removal of developer or admin rights.
• Every third violation, the developer will lose the commit access for one day.

Mailing lists

• 24 hours ban from the mailing list.
• Every third violation, the developer will get a 7 days ban.
• Ban from *-devel mailing list will get a ban from commit access for one day.
• For extreme violations, like spam, the first ban can be longer or infinite.

Disciplinary Actions for Escalated Conflicts

For escalated conflicts, disciplinary action must be decided on a case-by-case basis by Community Relations. For the majority of situations requiring disciplinary action, a warning is enough to correct future behavior. If behavior does not improve, a probationary period with revoked access to Gentoo infrastructure of two weeks to one month is appropriate. If upon restoration of access negative behavior re-occurs, removal from the project will be necessary. In extreme cases, suspension or removal may be necessary upon a single offense. Except in critical situations where immediate action is required, such disciplinary action is determined by members of the Community Relations project. If the issue is deemed critical, the developer in question may have his or her access suspended while a vote takes place. In such situations, the Community Relations lead may act without a vote of the remaining Community Relations team; this power is granted by Council. In the event of such a case, process for the resolution of the conflict may be bypassed altogether, a decision may be made, and any disputes would then be raised to Council per the below appeal process. The critical nature of an escalation may be determined by the Community Relations Lead or Infrastructure, for security-related issues, that which would endanger Gentoo, or our reputation. An issue that is deemed critical does not need further justification in addition to stating which of the above situations it falls under.

Upon removing a developer, the gentoo-core mailing list should be notified. Additionally, the entire Community Relations team is informed via email of the issues that led to removing or suspending a developer, and this information is stored on the bug. Developers who are removed from the project may not reapply for developer status without the approval of the Community Relations lead(s).