| .. _code_of_conduct_interpretation: |
| |
| Linux Kernel Contributor Covenant Code of Conduct Interpretation |
| ================================================================ |
| |
| The :ref:`code_of_conduct` is a general document meant to |
| provide a set of rules for almost any open source community. Every |
| open-source community is unique and the Linux kernel is no exception. |
| Because of this, this document describes how we in the Linux kernel |
| community will interpret it. We also do not expect this interpretation |
| to be static over time, and will adjust it as needed. |
| |
| The Linux kernel development effort is a very personal process compared |
| to "traditional" ways of developing software. Your contributions and |
| ideas behind them will be carefully reviewed, often resulting in |
| critique and criticism. The review will almost always require |
| improvements before the material can be included in the |
| kernel. Know that this happens because everyone involved wants to see |
| the best possible solution for the overall success of Linux. This |
| development process has been proven to create the most robust operating |
| system kernel ever, and we do not want to do anything to cause the |
| quality of submission and eventual result to ever decrease. |
| |
| Maintainers |
| ----------- |
| |
| The Code of Conduct uses the term "maintainers" numerous times. In the |
| kernel community, a "maintainer" is anyone who is responsible for a |
| subsystem, driver, or file, and is listed in the MAINTAINERS file in the |
| kernel source tree. |
| |
| Responsibilities |
| ---------------- |
| |
| The Code of Conduct mentions rights and responsibilities for |
| maintainers, and this needs some further clarifications. |
| |
| First and foremost, it is a reasonable expectation to have maintainers |
| lead by example. |
| |
| That being said, our community is vast and broad, and there is no new |
| requirement for maintainers to unilaterally handle how other people |
| behave in the parts of the community where they are active. That |
| responsibility is upon all of us, and ultimately the Code of Conduct |
| documents final escalation paths in case of unresolved concerns |
| regarding conduct issues. |
| |
| Maintainers should be willing to help when problems occur, and work with |
| others in the community when needed. Do not be afraid to reach out to |
| the Technical Advisory Board (TAB) or other maintainers if you're |
| uncertain how to handle situations that come up. It will not be |
| considered a violation report unless you want it to be. If you are |
| uncertain about approaching the TAB or any other maintainers, please |
| reach out to our conflict mediator, Joanna Lee <jlee@linuxfoundation.org>. |
| |
| In the end, "be kind to each other" is really what the end goal is for |
| everybody. We know everyone is human and we all fail at times, but the |
| primary goal for all of us should be to work toward amicable resolutions |
| of problems. Enforcement of the code of conduct will only be a last |
| resort option. |
| |
| Our goal of creating a robust and technically advanced operating system |
| and the technical complexity involved naturally require expertise and |
| decision-making. |
| |
| The required expertise varies depending on the area of contribution. It |
| is determined mainly by context and technical complexity and only |
| secondary by the expectations of contributors and maintainers. |
| |
| Both the expertise expectations and decision-making are subject to |
| discussion, but at the very end there is a basic necessity to be able to |
| make decisions in order to make progress. This prerogative is in the |
| hands of maintainers and project's leadership and is expected to be used |
| in good faith. |
| |
| As a consequence, setting expertise expectations, making decisions and |
| rejecting unsuitable contributions are not viewed as a violation of the |
| Code of Conduct. |
| |
| While maintainers are in general welcoming to newcomers, their capacity |
| of helping contributors overcome the entry hurdles is limited, so they |
| have to set priorities. This, also, is not to be seen as a violation of |
| the Code of Conduct. The kernel community is aware of that and provides |
| entry level programs in various forms like kernelnewbies.org. |
| |
| Scope |
| ----- |
| |
| The Linux kernel community primarily interacts on a set of public email |
| lists distributed around a number of different servers controlled by a |
| number of different companies or individuals. All of these lists are |
| defined in the MAINTAINERS file in the kernel source tree. Any emails |
| sent to those mailing lists are considered covered by the Code of |
| Conduct. |
| |
| Developers who use the kernel.org bugzilla, and other subsystem bugzilla |
| or bug tracking tools should follow the guidelines of the Code of |
| Conduct. The Linux kernel community does not have an "official" project |
| email address, or "official" social media address. Any activity |
| performed using a kernel.org email account must follow the Code of |
| Conduct as published for kernel.org, just as any individual using a |
| corporate email account must follow the specific rules of that |
| corporation. |
| |
| The Code of Conduct does not prohibit continuing to include names, email |
| addresses, and associated comments in mailing list messages, kernel |
| change log messages, or code comments. |
| |
| Interaction in other forums is covered by whatever rules apply to said |
| forums and is in general not covered by the Code of Conduct. Exceptions |
| may be considered for extreme circumstances. |
| |
| Contributions submitted for the kernel should use appropriate language. |
| Content that already exists predating the Code of Conduct will not be |
| addressed now as a violation. Inappropriate language can be seen as a |
| bug, though; such bugs will be fixed more quickly if any interested |
| parties submit patches to that effect. Expressions that are currently |
| part of the user/kernel API, or reflect terminology used in published |
| standards or specifications, are not considered bugs. |
| |
| Enforcement |
| ----------- |
| |
| The address listed in the Code of Conduct goes to the Code of Conduct |
| Committee. The exact members receiving these emails at any given time |
| are listed at https://kernel.org/code-of-conduct.html. Members can not |
| access reports made before they joined or after they have left the |
| committee. |
| |
| The Code of Conduct Committee consists of volunteer community members |
| appointed by the TAB, as well as a professional mediator acting as a |
| neutral third party. The processes the Code of Conduct committee will |
| use to address reports is varied and will depend on the individual |
| circumstance, however, this file serves as documentation for the |
| general process used. |
| |
| Any member of the committee, including the mediator, can be contacted |
| directly if a reporter does not wish to include the full committee in a |
| complaint or concern. |
| |
| The Code of Conduct Committee reviews the cases according to the |
| processes (see above) and consults with the TAB as needed and |
| appropriate, for instance to request and receive information about the |
| kernel community. |
| |
| Any decisions regarding enforcement recommendations will be brought to |
| the TAB for implementation of enforcement with the relevant maintainers |
| if needed. A decision by the Code of Conduct Committee can be overturned |
| by the TAB by a two-thirds vote. |
| |
| At quarterly intervals, the Code of Conduct Committee and TAB will |
| provide a report summarizing the anonymised reports that the Code of |
| Conduct committee has received and their status, as well details of any |
| overridden decisions including complete and identifiable voting details. |
| |
| Because how we interpret and enforce the Code of Conduct will evolve over |
| time, this document will be updated when necessary to reflect any |
| changes. |