Documentation/process: Add Linux Kernel Contribution Maturity Model

As a follow-up to a discussion at the 2021 Maintainer's Summit on the
topic of maintainer recruitment and retention, the TAB took on the
task of creating a document which to help companies and other
organizations to grow in their ability to engage with the Linux Kernel
development community, using the Maturity Model[2] framework.

The goal is to encourage, in a management-friendly way, companies to
allow their engineers to contribute with the upstream Linux Kernel
development community, so we can grow the "talent pipeline" for
contributors to become respected leaders, and eventually kernel
maintainers.

[1] https://lwn.net/Articles/870581/
[2] https://en.wikipedia.org/wiki/Maturity_model

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Co-developed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Acked-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20230308190403.2157046-1-tytso@mit.edu
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Theodore Ts'o 2023-03-08 14:04:03 -05:00 committed by Jonathan Corbet
parent 456ef6b083
commit 10a29eb658
3 changed files with 118 additions and 0 deletions

View File

@ -0,0 +1,109 @@
.. SPDX-License-Identifier: GPL-2.0
========================================
Linux Kernel Contribution Maturity Model
========================================
Background
==========
As a part of the 2021 Linux Kernel Maintainers Summit, there was a
`discussion <https://lwn.net/Articles/870581/>`_ about the challenges in
recruiting kernel maintainers as well as maintainer succession. Some of
the conclusions from that discussion included that companies which are a
part of the Linux Kernel community need to allow engineers to be
maintainers as part of their job, so they can grow into becoming
respected leaders and eventually, kernel maintainers. To support a
strong talent pipeline, developers should be allowed and encouraged to
take on upstream contributions such as reviewing other peoples patches,
refactoring kernel infrastructure, and writing documentation.
To that end, the Linux Foundation Technical Advisory Board (TAB)
proposes this Linux Kernel Contribution Maturity Model. These common
expectations for upstream community engagement aim to increase the
influence of individual developers, increase the collaboration of
organizations, and improve the overall health of the Linux Kernel
ecosystem.
The TAB urges organizations to continuously evaluate their Open Source
maturity model and commit to improvements to align with this model. To
be effective, this evaluation should incorporate feedback from across
the organization, including management and developers at all seniority
levels. In the spirit of Open Source, we encourage organizations to
publish their evaluations and plans to improve their engagement with the
upstream community.
Level 0
=======
* Software Engineers are not allowed to contribute patches to the Linux
kernel.
Level 1
=======
* Software Engineers are allowed to contribute patches to the Linux
kernel, either as part of their job responsibilities or on their own
time.
Level 2
=======
* Software Engineers are expected to contribute to the Linux Kernel as
part of their job responsibilities.
* Software Engineers will be supported to attend Linux-related
conferences as a part of their job.
* A Software Engineers upstream code contributions will be considered
in promotion and performance reviews.
Level 3
=======
* Software Engineers are expected to review patches (including patches
authored by engineers from other companies) as part of their job
responsibilities
* Contributing presentations or papers to Linux-related or academic
conferences (such those organized by the Linux Foundation, Usenix,
ACM, etc.), are considered part of an engineers work.
* A Software Engineers community contributions will be considered in
promotion and performance reviews.
* Organizations will regularly report metrics of their open source
contributions and track these metrics over time. These metrics may be
published only internally within the organization, or at the
organizations discretion, some or all may be published externally.
Metrics that are strongly suggested include:
* The number of upstream kernel contributions by team or organization
(e.g., all people reporting up to a manager, director, or VP).
* The percentage of kernel developers who have made upstream
contributions relative to the total kernel developers in the
organization.
* The time interval between kernels used in the organizations servers
and/or products, and the publication date of the upstream kernel
upon which the internal kernel is based.
* The number of out-of-tree commits present in internal kernels.
Level 4
=======
* Software Engineers are encouraged to spend a portion of their work
time focused on Upstream Work, which is defined as reviewing patches,
serving on program committees, improving core project infrastructure
such as writing or maintaining tests, upstream tech debt reduction,
writing documentation, etc.
* Software Engineers are supported in helping to organize Linux-related
conferences.
* Organizations will consider community member feedback in official
performance reviews.
Level 5
=======
* Upstream kernel development is considered a formal job position, with
at least a third of the engineers time spent doing Upstream Work.
* Organizations will actively seek out community member feedback as a
factor in official performance reviews.
* Organizations will regularly report internally on the ratio of
Upstream Work to work focused on directly pursuing business goals.

View File

@ -50,6 +50,7 @@ Other guides to the community that are of interest to most developers are:
embargoed-hardware-issues
maintainers
researcher-guidelines
contribution-maturity-model
These are some overall technical guides that have been put here for now for
lack of a better place.

View File

@ -21244,6 +21244,14 @@ S: Maintained
F: Documentation/tools/rtla/
F: tools/tracing/rtla/
TECHNICAL ADVISORY BOARD PROCESS DOCS
M: "Theodore Ts'o" <tytso@mit.edu>
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
L: tech-board-discuss@lists.linux-foundation.org
S: Maintained
F: Documentation/process/researcher-guidelines.rst
F: Documentation/process/contribution-maturity-model.rst
TRADITIONAL CHINESE DOCUMENTATION
M: Hu Haowen <src.res@email.cn>
L: linux-doc-tw-discuss@lists.sourceforge.net (moderated for non-subscribers)