Hello, On 12/14/2022 10:57 AM, Theodore Ts'o wrote:
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@xxxxxxx> Co-developed-by: Kees Cook <keescook@xxxxxxxxxxxx> Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx> Co-developed-by: Dan Williams <dan.j.williams@xxxxxxxxx> Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> Acked-by: Jakub Kicinski <kuba@xxxxxxxxxx> Acked-by: Christian Brauner (Microsoft) <brauner@xxxxxxxxxx> Acked-by: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> ---
[snip]
+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.
You probably need to provide a word or two about who is the intended recipient of this document, whether this is intended to be utilized by software developers, their management chain, or both.
+ +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.
This is not something IMHO that qualifies for Level 2, but rather for Level 3. It is reasonably simple and easy for companies to support their engineers contributing to the kernel, it is a whole different thing to financially support them to attend conference(s).
+* A Software Engineer’s upstream code contributions shall 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
Would substitute expected with highly encouraged here.
+* Contributing presentations or papers to Linux-related conferences are + considered part of an engineer’s work.
Again, that seems more of a Level 4 item to me.
+* A Software Engineer’s community contributions shall be considered in + promotion and performance reviews. +* Organizations shall 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 engineer, team, and + 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.
That part is a bit difficult to generalize, so as a broad definition of metrics to track, it seems appropriate as a possible example. In practice lots of people have to work within the bounds of the kernel they are provided with, and they may not always entirely control the contribution process behind as much as the code getting in. It seems to me that we have usually following categories:
- everything lands upstream and/or working upstream first which is the case with Intel, AMD, Meta, Oracle, etc.
- maintaining a major distribution kernel: Android, RedHat, SUSE, Oracle UKE with as much upstream code downstream as downstream code reaching upstream eventually
- working with a well maintained downstream kernel tree based upon a LTS version from a vendor where most SoCs companies fall these days hopefully
- working with a not so major distribution kernel in the likes of OpenWrt etc.
- unmaintained kernel
+ * The number of out-of-tree commits present in internal kernels.
The metrics that an organization must provide versus the level a given engineer is at is independent from one another, or rather, you may want to create different levels, one for engineers which is what you have, and one for organizations.
So maybe there needs to be 4 levels for an organization: 0 - no support/awareness/will to engage1 - mild engagement with the community in one form of another, including maintenance of metrics 2 - organization is largely supportive of upstream work and does so with pouring some occasional resources to attend/organize conferences, albeit not at the "gold" sponsor level 3 - organization heavily leans on upstream work for its products and is a regular sponsor at major events
+ +Level 4 +======= + +* Software Engineers are encouraged to spend a portion of their work + time focused on Upstream Work, which is defined as reviewing patches + or papers, 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.
Likewise, this seems to be more of a Level 5 aspect rather than Level 4.
+* Organizations shall consider community member feedback in official + performance reviews. + +Level 5
And I would make this essentially Level 6.
+======= + +* Upstream kernel development is considered a formal job position, with + at least a third of the engineer’s time spent doing Upstream Work. +* Organizations shall actively seek out community member feedback as a + factor in official performance reviews. +* Organizations shall regularly report internally on the ratio of + Upstream Work to work focused on directly pursuing business goals. diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index d4b6217472b0..33715da7e684 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -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-modelThese are some overall technical guides that have been put here for now forlack of a better place.
-- Florian
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
