110 lines
4.4 KiB
ReStructuredText
110 lines
4.4 KiB
ReStructuredText
|
.. 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 people’s 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 Engineer’s 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 engineer’s work.
|
|||
|
|
* A Software Engineer’s 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
|
|||
|
|
organization’s 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 organization’s 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 engineer’s 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.
|