tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

Code of Conduct Interpretation: Add document explaining how the Code of Conduct is to be interpreted

The Contributor Covenant 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.

This document was created with the input and feedback of the TAB as well
as many current kernel maintainers.

Co-Developed-by: Thomas Gleixner <tglx@linutronix.de>
Co-Developed-by: Olof Johansson <olof@lixom.net>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Amir Goldstein <amir73il@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Andy Lutomirski <luto@kernel.org>
Acked-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Acked-by: Borislav Petkov <bp@kernel.org>
Acked-by: Chris Mason <clm@fb.com>
Acked-by: Christian Lütke-Stetzkamp <christian@lkamp.de>
Acked-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: David Ahern <dsa@cumulusnetworks.com>
Acked-by: David Sterba <kdave@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.de>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Felipe Balbi <balbi@kernel.org>
Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: Hans de Goede <j.w.r.degoede@gmail.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Jaegeuk Kim <jaegeuk@kernel.org>
Acked-by: James Smart <james.smart@broadcom.com>
Acked-by: James Smart <jsmart2021@gmail.com>
Acked-by: Jan Kara <jack@ucw.cz>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Acked-by: Jessica Yu <jeyu@kernel.org>
Acked-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Acked-by: Jiri Kosina <jikos@kernel.org>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Acked-by: Joerg Roedel <joro@8bytes.org>
Acked-by: Johan Hovold <johan@kernel.org>
Acked-by: Johannes Thumshirn <jth@kernel.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Lina Iyer <ilina@codeaurora.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Acked-by: Matias Bjørling <mb@lightnvm.io>
Acked-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Mimi Zohar <zohar@linux.ibm.com>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Mishi Choudhary <mishi@linux.com>
Acked-by: Nikolay Borisov <n.borisov.lkml@gmail.com>
Acked-by: Oded Gabbay <oded.gabbay@gmail.com>
Acked-by: Palmer Dabbelt <palmer@dabbelt.com>
Acked-by: Paul E. McKenney <paulmck@linux.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Acked-by: Richard Weinberger <richard@nod.at>
Acked-by: Rik van Riel <riel@surriel.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Sean Paul <sean@poorly.run>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Sebastian Reichel <sre@kernel.org>
Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Acked-by: Shuah Khan <shuah@kernel.org>
Acked-by: Simon Horman <horms@verge.net.au>
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Takashi Iwai <tiwai@kernel.org>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Todd Poynor <toddpoynor@google.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Greg Kroah-Hartman 79dbeed3 c1d1ba84

+154
+153
Documentation/process/code-of-conduct-interpretation.rst
··· 1 + Linux Kernel Contributor Covenant Code of Conduct Interpretation 2 + ================================================================ 3 + 4 + The Contributor Covenant Code of Conduct is a general document meant to 5 + provide a set of rules for almost any open source community. Every 6 + open-source community is unique and the Linux kernel is no exception. 7 + Because of this, this document describes how we in the Linux kernel 8 + community will interpret it. We also do not expect this interpretation 9 + to be static over time, and will adjust it as needed. 10 + 11 + The Linux kernel development effort is a very personal process compared 12 + to "traditional" ways of developing software. Your contributions and 13 + ideas behind them will be carefully reviewed, often resulting in 14 + critique and criticism. The review will almost always require 15 + improvements before the material can be included in the 16 + kernel. Know that this happens because everyone involved wants to see 17 + the best possible solution for the overall success of Linux. This 18 + development process has been proven to create the most robust operating 19 + system kernel ever, and we do not want to do anything to cause the 20 + quality of submission and eventual result to ever decrease. 21 + 22 + Maintainers 23 + ----------- 24 + 25 + The Code of Conduct uses the term "maintainers" numerous times. In the 26 + kernel community, a "maintainer" is anyone who is responsible for a 27 + subsystem, driver, or file, and is listed in the MAINTAINERS file in the 28 + kernel source tree. 29 + 30 + Responsibilities 31 + ---------------- 32 + 33 + The Code of Conduct mentions rights and responsibilities for 34 + maintainers, and this needs some further clarifications. 35 + 36 + First and foremost, it is a reasonable expectation to have maintainers 37 + lead by example. 38 + 39 + That being said, our community is vast and broad, and there is no new 40 + requirement for maintainers to unilaterally handle how other people 41 + behave in the parts of the community where they are active. That 42 + responsibility is upon all of us, and ultimately the Code of Conduct 43 + documents final escalation paths in case of unresolved concerns 44 + regarding conduct issues. 45 + 46 + Maintainers should be willing to help when problems occur, and work with 47 + others in the community when needed. Do not be afraid to reach out to 48 + the TAB or other maintainers if you're uncertain how to handle 49 + situations that come up. It will not be considered a violation report 50 + unless you want it to be. If you are uncertain about approaching the 51 + TAB or any other maintainers, please reach out to our conflict mediator, 52 + Mishi Choudhary <mishi@linux.com>. 53 + 54 + In the end, "be kind to each other" is really what the end goal is for 55 + everybody. We know everyone is human and we all fail at times, but the 56 + primary goal for all of us should be to work toward amicable resolutions 57 + of problems. Enforcement of the code of conduct will only be a last 58 + resort option. 59 + 60 + Our goal of creating a robust and technically advanced operating system 61 + and the technical complexity involved naturally require expertise and 62 + decision-making. 63 + 64 + The required expertise varies depending on the area of contribution. It 65 + is determined mainly by context and technical complexity and only 66 + secondary by the expectations of contributors and maintainers. 67 + 68 + Both the expertise expectations and decision-making are subject to 69 + discussion, but at the very end there is a basic necessity to be able to 70 + make decisions in order to make progress. This prerogative is in the 71 + hands of maintainers and project's leadership and is expected to be used 72 + in good faith. 73 + 74 + As a consequence, setting expertise expectations, making decisions and 75 + rejecting unsuitable contributions are not viewed as a violation of the 76 + Code of Conduct. 77 + 78 + While maintainers are in general welcoming to newcomers, their capacity 79 + of helping contributors overcome the entry hurdles is limited, so they 80 + have to set priorities. This, also, is not to be seen as a violation of 81 + the Code of Conduct. The kernel community is aware of that and provides 82 + entry level programs in various forms like kernelnewbies.org. 83 + 84 + Scope 85 + ----- 86 + 87 + The Linux kernel community primarily interacts on a set of public email 88 + lists distributed around a number of different servers controlled by a 89 + number of different companies or individuals. All of these lists are 90 + defined in the MAINTAINERS file in the kernel source tree. Any emails 91 + sent to those mailing lists are considered covered by the Code of 92 + Conduct. 93 + 94 + Developers who use the kernel.org bugzilla, and other subsystem bugzilla 95 + or bug tracking tools should follow the guidelines of the Code of 96 + Conduct. The Linux kernel community does not have an "official" project 97 + email address, or "official" social media address. Any activity 98 + performed using a kernel.org email account must follow the Code of 99 + Conduct as published for kernel.org, just as any individual using a 100 + corporate email account must follow the specific rules of that 101 + corporation. 102 + 103 + The Code of Conduct does not prohibit continuing to include names, email 104 + addresses, and associated comments in mailing list messages, kernel 105 + change log messages, or code comments. 106 + 107 + Interaction in other forums is covered by whatever rules apply to said 108 + forums and is in general not covered by the Code of Conduct. Exceptions 109 + may be considered for extreme circumstances. 110 + 111 + Contributions submitted for the kernel should use appropriate language. 112 + Content that already exists predating the Code of Conduct will not be 113 + addressed now as a violation. Inappropriate language can be seen as a 114 + bug, though; such bugs will be fixed more quickly if any interested 115 + parties submit patches to that effect. Expressions that are currently 116 + part of the user/kernel API, or reflect terminology used in published 117 + standards or specifications, are not considered bugs. 118 + 119 + Enforcement 120 + ----------- 121 + 122 + The address listed in the Code of Conduct goes to the Code of Conduct 123 + Committee. The exact members receiving these emails at any given time 124 + are listed at <URL>. Members can not access reports made before they 125 + joined or after they have left the committee. 126 + 127 + The initial Code of Conduct Committee consists of volunteer members of 128 + the Technical Advisory Board (TAB), as well as a professional mediator 129 + acting as a neutral third party. The first task of the committee is to 130 + establish documented processes, which will be made public. 131 + 132 + Any member of the committee, including the mediator, can be contacted 133 + directly if a reporter does not wish to include the full committee in a 134 + complaint or concern. 135 + 136 + The Code of Conduct Committee reviews the cases according to the 137 + processes (see above) and consults with the TAB as needed and 138 + appropriate, for instance to request and receive information about the 139 + kernel community. 140 + 141 + Any decisions by the committee will be brought to the TAB, for 142 + implementation of enforcement with the relevant maintainers if needed. 143 + A decision by the Code of Conduct Committee can be overturned by the TAB 144 + by a two-thirds vote. 145 + 146 + At quarterly intervals, the Code of Conduct Committee and TAB will 147 + provide a report summarizing the anonymised reports that the Code of 148 + Conduct committee has received and their status, as well details of any 149 + overridden decisions including complete and identifiable voting details. 150 + 151 + We expect to establish a different process for Code of Conduct Committee 152 + staffing beyond the bootstrap period. This document will be updated 153 + with that information when this occurs.
+1
Documentation/process/index.rst
··· 21 21 22 22 howto 23 23 code-of-conduct 24 + code-of-conduct-interpretation 24 25 development-process 25 26 submitting-patches 26 27 coding-style