contribution-maturity-model.rst 4.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109
  1. .. SPDX-License-Identifier: GPL-2.0
  2. ========================================
  3. Linux Kernel Contribution Maturity Model
  4. ========================================
  5. Background
  6. ==========
  7. As a part of the 2021 Linux Kernel Maintainers’ Summit, there was a
  8. `discussion <https://lwn.net/Articles/870581/>`_ about the challenges in
  9. recruiting kernel maintainers as well as maintainer succession. Some of
  10. the conclusions from that discussion included that companies which are a
  11. part of the Linux Kernel community need to allow engineers to be
  12. maintainers as part of their job, so they can grow into becoming
  13. respected leaders and eventually, kernel maintainers. To support a
  14. strong talent pipeline, developers should be allowed and encouraged to
  15. take on upstream contributions such as reviewing other people’s patches,
  16. refactoring kernel infrastructure, and writing documentation.
  17. To that end, the Linux Foundation Technical Advisory Board (TAB)
  18. proposes this Linux Kernel Contribution Maturity Model. These common
  19. expectations for upstream community engagement aim to increase the
  20. influence of individual developers, increase the collaboration of
  21. organizations, and improve the overall health of the Linux Kernel
  22. ecosystem.
  23. The TAB urges organizations to continuously evaluate their Open Source
  24. maturity model and commit to improvements to align with this model. To
  25. be effective, this evaluation should incorporate feedback from across
  26. the organization, including management and developers at all seniority
  27. levels. In the spirit of Open Source, we encourage organizations to
  28. publish their evaluations and plans to improve their engagement with the
  29. upstream community.
  30. Level 0
  31. =======
  32. * Software Engineers are not allowed to contribute patches to the Linux
  33. kernel.
  34. Level 1
  35. =======
  36. * Software Engineers are allowed to contribute patches to the Linux
  37. kernel, either as part of their job responsibilities or on their own
  38. time.
  39. Level 2
  40. =======
  41. * Software Engineers are expected to contribute to the Linux Kernel as
  42. part of their job responsibilities.
  43. * Software Engineers will be supported to attend Linux-related
  44. conferences as a part of their job.
  45. * A Software Engineer’s upstream code contributions will be considered
  46. in promotion and performance reviews.
  47. Level 3
  48. =======
  49. * Software Engineers are expected to review patches (including patches
  50. authored by engineers from other companies) as part of their job
  51. responsibilities
  52. * Contributing presentations or papers to Linux-related or academic
  53. conferences (such those organized by the Linux Foundation, Usenix,
  54. ACM, etc.), are considered part of an engineer’s work.
  55. * A Software Engineer’s community contributions will be considered in
  56. promotion and performance reviews.
  57. * Organizations will regularly report metrics of their open source
  58. contributions and track these metrics over time. These metrics may be
  59. published only internally within the organization, or at the
  60. organization’s discretion, some or all may be published externally.
  61. Metrics that are strongly suggested include:
  62. * The number of upstream kernel contributions by team or organization
  63. (e.g., all people reporting up to a manager, director, or VP).
  64. * The percentage of kernel developers who have made upstream
  65. contributions relative to the total kernel developers in the
  66. organization.
  67. * The time interval between kernels used in the organization’s servers
  68. and/or products, and the publication date of the upstream kernel
  69. upon which the internal kernel is based.
  70. * The number of out-of-tree commits present in internal kernels.
  71. Level 4
  72. =======
  73. * Software Engineers are encouraged to spend a portion of their work
  74. time focused on Upstream Work, which is defined as reviewing patches,
  75. serving on program committees, improving core project infrastructure
  76. such as writing or maintaining tests, upstream tech debt reduction,
  77. writing documentation, etc.
  78. * Software Engineers are supported in helping to organize Linux-related
  79. conferences.
  80. * Organizations will consider community member feedback in official
  81. performance reviews.
  82. Level 5
  83. =======
  84. * Upstream kernel development is considered a formal job position, with
  85. at least a third of the engineer’s time spent doing Upstream Work.
  86. * Organizations will actively seek out community member feedback as a
  87. factor in official performance reviews.
  88. * Organizations will regularly report internally on the ratio of
  89. Upstream Work to work focused on directly pursuing business goals.