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.
• Try not to flame; it is not polite.
• 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 to Community Relations.

Gentoo has a number of IRC channels. Each channel has a number of operators managing it and ensuring proper use of this media. Community Relations has faith that the current operators are capable to manage their channels so it will not interfere with them unless a conflict is escalated to Community Relations by the channel operators or a user. However, there are a few channels where all developers are operators such as #gentoo-dev. In this case, Community Relations will actively enforce the CoC and impose the following list of possible penalties if necessary.

• 24 hour ban from the IRC channel.
• Every third ban is followed by a 7 day ban.
• For repetitive violations, the case may be escalated to Community Relations for further disciplinary actions

For CoC violations in bugzilla the following list of disciplinary actions may be followed.

• 48 hour ban from bugzilla.
• Every third violation, the developer will lose his/her cvs access for two days.
• For repetitive violations, the case may be escalated to Community Relations for further disciplinary actions.

For CoC violations in the mailing list, the following list of disciplinary actions may be followed.

• 7 days ban from the mailing list.
• Every third violation is followed by a 30 days ban.
• For repetitive violations, the case may be escalated to Community Relations for further disciplinary actions.

In case a disciplinary action is applied, one of the ComRel members must e-mail the offender as soon as possible informing him of the situation and possible consequences for repetitive violations.

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).