Documentation/process/code-of-conduct-interpretation.rst
Source file repositories/reference/linux-study-clean/Documentation/process/code-of-conduct-interpretation.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/process/code-of-conduct-interpretation.rst- Extension
.rst- Size
- 12195 bytes
- Lines
- 251
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. _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
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.