121 lines
5.4 KiB
ReStructuredText
121 lines
5.4 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
|
.. include:: ../disclaimer-sp.rst
|
|
|
|
:Original: Documentation/process/contribution-maturity-model.rst
|
|
:Translator: Avadhut Naik <avadhut.naik@amd.com>
|
|
|
|
====================================================
|
|
Modelo de Madurez de Contribución al Kernel de Linux
|
|
====================================================
|
|
|
|
|
|
Los Antecedentes
|
|
================
|
|
|
|
Como parte de la cumbre de mantenedores del kernel de Linux 2021, hubo
|
|
una `discusión <https://lwn.net/Articles/870581/>`_ sobre los desafíos
|
|
en el reclutamiento de mantenedores del kernel, así como la sucesión de
|
|
los mantenedores. Algunas de las conclusiones de esa discusión incluyeron
|
|
que las empresas que forman parte de la comunidad del kernel de Linux
|
|
necesitan permitir que los ingenieros sean mantenedores como parte de su
|
|
trabajo, para que puedan convertirse en lideres respetados y finalmente,
|
|
en mantenedores del kernel. Para apoyar una fuente solida de talento, se
|
|
debe permitir y alentar a los desarrolladores a asumir contribuciones
|
|
upstream, como revisar los parches de otras personas, reestructurar la
|
|
infraestructura del kernel y escribir documentación.
|
|
|
|
Con ese fin, Technical Advisory Board (TAB) de la Fundación Linux propone
|
|
este Modelo de Madurez de Contribución al Kernel de Linux. Estas
|
|
expectativas comunes para la participación con la comunidad upstream
|
|
tienen como objetivo aumentar la influencia de los desarrolladores
|
|
individuales, aumentar la colaboración de las organizaciones y mejorar
|
|
la salud general del ecosistema del kernel de Linux.
|
|
|
|
El TAB insta a las organizaciones a evaluar continuamente su modelo de
|
|
madurez de Código Abierto y comprometerse a realizar mejoras para
|
|
alinearse con este modelo. Para ser eficaz, esta evaluación debe
|
|
incorporar la reacción de toda la organización, incluyendo la gerencia
|
|
y los desarrolladores en todos los niveles de antigüedad. En el espíritu
|
|
de Código Abierto, alentamos a las organizaciones a publicar sus
|
|
evaluaciones y planes para mejorar su participación con la comunidad
|
|
upstream.
|
|
|
|
Nivel 0
|
|
=======
|
|
|
|
* A los ingenieros de software no se les permite contribuir con parches
|
|
al kernel de Linux.
|
|
|
|
Nivel 1
|
|
=======
|
|
|
|
* A los ingenieros de software se les permite contribuir con parches al
|
|
kernel de Linux, ya sea como parte de sus responsabilidades de trabajo
|
|
o en su propio tiempo.
|
|
|
|
Nivel 2
|
|
=======
|
|
|
|
* Se espera que los ingenieros de software contribuyan al kernel de Linux
|
|
como parte de sus responsabilidades de trabajo.
|
|
* Se proporcionará apoyo a los ingenieros de software para asistir a
|
|
conferencias relacionadas con Linux como parte de su trabajo.
|
|
* Las contribuciones de código upstream de un ingeniero de software se
|
|
considerarán en la promoción y las revisiones de rendimiento.
|
|
|
|
Nivel 3
|
|
=======
|
|
|
|
* Se espera que los ingenieros de software revisen los parches (incluidos
|
|
los parches escritos por ingenieros de otras empresas) como parte de
|
|
sus responsabilidades de trabajo.
|
|
* Contribuir con presentaciones o ponencias a conferencias relacionadas
|
|
con Linux o académicas (como las organizadas por la Fundación Linux,
|
|
Usenix, ACM, etc.), se consideran parte del trabajo de un ingeniero.
|
|
* Las contribuciones a la comunidad de un ingeniero de software se
|
|
considerarán en la promoción y las revisiones de rendimiento.
|
|
* Las organizaciones informarán regularmente sobre las métricas de sus
|
|
contribuciones de código abierto y harán un seguimiento de estas
|
|
métricas a lo largo del tiempo. Estas métricas pueden publicarse
|
|
solo internamente dentro de la organización, o a discreción de la
|
|
organización, algunas o todas pueden publicarse externamente. Las
|
|
métricas que se sugieren encarecidamente incluyen:
|
|
|
|
* El número de contribuciones al kernel upstream por equipo u
|
|
organización (por ejemplo, todas las personas que reportan a un
|
|
gerente o director o vicepresidente).
|
|
* El porcentaje de desarrolladores del kernel que han realizado
|
|
contribuciones upstream relativo al total de desarrolladores
|
|
del kernel en la organización.
|
|
* El intervalo de tiempo entre los kernels utilizados en los servidores
|
|
y/o productos de la organización y la fecha de publicación del kernel
|
|
upstream en el que se basa el kernel interno.
|
|
* El número de commits fuera del árbol de desarrollo presentes en los
|
|
kernels internos.
|
|
|
|
Nivel 4
|
|
=======
|
|
|
|
* Se anima a los ingenieros de software a pasar una parte de su tiempo de
|
|
trabajo centrado en el Trabajo Ascendente, que se define como revisar
|
|
parches, servir en los comités de programas, mejorar la infraestructura
|
|
del proyecto central como escribir o mantener pruebas, reducir la deuda
|
|
de tecnología upstream, escribir documentación, etc.
|
|
* Los ingenieros de software son apoyados para ayudar a organizar
|
|
conferencias relacionadas con Linux.
|
|
* Las organizaciones considerarán los comentarios de los miembros de la
|
|
comunidad en las revisiones oficiales de rendimiento.
|
|
|
|
Nivel 5
|
|
=======
|
|
|
|
* El desarrollo del kernel upstream se considera un puesto de trabajo
|
|
formal, con al menos un tercio del tiempo del ingeniero pasado a hacer
|
|
el Trabajo Ascendente.
|
|
* Las organizaciones buscarán activamente las reacciones de los miembros
|
|
de la comunidad como un factor en las revisiones oficiales de
|
|
rendimiento.
|
|
* Las organizaciones informarán regularmente internamente sobre la ratio
|
|
de trabajo upstream a trabajo enfocado en perseguir directamente los
|
|
objetivos comerciales.
|