tjh.dev
Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
docs/sp_SP: Add translation of process/contribution-maturity-model
Translate Documentation/process/contribution-maturity-model.rst into
Spanish
Signed-off-by: Avadhut Naik <avadhut.naik@amd.com>
Reviewed-by: Carlos Bilbao <carlos.bilbao@amd.com>
[ jc: fix added warning for nonexistent ref ]
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20230717181602.3468421-1-avadhut.naik@amd.com
authored by
Avadhut Naik
and committed by
Jonathan Corbet
1e6f64c5
4454d382
+121
+120
Documentation/translations/sp_SP/process/contribution-maturity-model.rst
+120
Documentation/translations/sp_SP/process/contribution-maturity-model.rst
···
1
+
.. SPDX-License-Identifier: GPL-2.0
2
+
.. include:: ../disclaimer-sp.rst
3
+
4
+
:Original: Documentation/process/contribution-maturity-model.rst
5
+
:Translator: Avadhut Naik <avadhut.naik@amd.com>
6
+
7
+
====================================================
8
+
Modelo de Madurez de Contribución al Kernel de Linux
9
+
====================================================
10
+
11
+
12
+
Los Antecedentes
13
+
================
14
+
15
+
Como parte de la cumbre de mantenedores del kernel de Linux 2021, hubo
16
+
una `discusión <https://lwn.net/Articles/870581/>`_ sobre los desafíos
17
+
en el reclutamiento de mantenedores del kernel, así como la sucesión de
18
+
los mantenedores. Algunas de las conclusiones de esa discusión incluyeron
19
+
que las empresas que forman parte de la comunidad del kernel de Linux
20
+
necesitan permitir que los ingenieros sean mantenedores como parte de su
21
+
trabajo, para que puedan convertirse en lideres respetados y finalmente,
22
+
en mantenedores del kernel. Para apoyar una fuente solida de talento, se
23
+
debe permitir y alentar a los desarrolladores a asumir contribuciones
24
+
upstream, como revisar los parches de otras personas, reestructurar la
25
+
infraestructura del kernel y escribir documentación.
26
+
27
+
Con ese fin, Technical Advisory Board (TAB) de la Fundación Linux propone
28
+
este Modelo de Madurez de Contribución al Kernel de Linux. Estas
29
+
expectativas comunes para la participación con la comunidad upstream
30
+
tienen como objetivo aumentar la influencia de los desarrolladores
31
+
individuales, aumentar la colaboración de las organizaciones y mejorar
32
+
la salud general del ecosistema del kernel de Linux.
33
+
34
+
El TAB insta a las organizaciones a evaluar continuamente su modelo de
35
+
madurez de Código Abierto y comprometerse a realizar mejoras para
36
+
alinearse con este modelo. Para ser eficaz, esta evaluación debe
37
+
incorporar la reacción de toda la organización, incluyendo la gerencia
38
+
y los desarrolladores en todos los niveles de antigüedad. En el espíritu
39
+
de Código Abierto, alentamos a las organizaciones a publicar sus
40
+
evaluaciones y planes para mejorar su participación con la comunidad
41
+
upstream.
42
+
43
+
Nivel 0
44
+
=======
45
+
46
+
* A los ingenieros de software no se les permite contribuir con parches
47
+
al kernel de Linux.
48
+
49
+
Nivel 1
50
+
=======
51
+
52
+
* A los ingenieros de software se les permite contribuir con parches al
53
+
kernel de Linux, ya sea como parte de sus responsabilidades de trabajo
54
+
o en su propio tiempo.
55
+
56
+
Nivel 2
57
+
=======
58
+
59
+
* Se espera que los ingenieros de software contribuyan al kernel de Linux
60
+
como parte de sus responsabilidades de trabajo.
61
+
* Se proporcionará apoyo a los ingenieros de software para asistir a
62
+
conferencias relacionadas con Linux como parte de su trabajo.
63
+
* Las contribuciones de código upstream de un ingeniero de software se
64
+
considerarán en la promoción y las revisiones de rendimiento.
65
+
66
+
Nivel 3
67
+
=======
68
+
69
+
* Se espera que los ingenieros de software revisen los parches (incluidos
70
+
los parches escritos por ingenieros de otras empresas) como parte de
71
+
sus responsabilidades de trabajo.
72
+
* Contribuir con presentaciones o ponencias a conferencias relacionadas
73
+
con Linux o académicas (como las organizadas por la Fundación Linux,
74
+
Usenix, ACM, etc.), se consideran parte del trabajo de un ingeniero.
75
+
* Las contribuciones a la comunidad de un ingeniero de software se
76
+
considerarán en la promoción y las revisiones de rendimiento.
77
+
* Las organizaciones informarán regularmente sobre las métricas de sus
78
+
contribuciones de código abierto y harán un seguimiento de estas
79
+
métricas a lo largo del tiempo. Estas métricas pueden publicarse
80
+
solo internamente dentro de la organización, o a discreción de la
81
+
organización, algunas o todas pueden publicarse externamente. Las
82
+
métricas que se sugieren encarecidamente incluyen:
83
+
84
+
* El número de contribuciones al kernel upstream por equipo u
85
+
organización (por ejemplo, todas las personas que reportan a un
86
+
gerente o director o vicepresidente).
87
+
* El porcentaje de desarrolladores del kernel que han realizado
88
+
contribuciones upstream relativo al total de desarrolladores
89
+
del kernel en la organización.
90
+
* El intervalo de tiempo entre los kernels utilizados en los servidores
91
+
y/o productos de la organización y la fecha de publicación del kernel
92
+
upstream en el que se basa el kernel interno.
93
+
* El número de commits fuera del árbol de desarrollo presentes en los
94
+
kernels internos.
95
+
96
+
Nivel 4
97
+
=======
98
+
99
+
* Se anima a los ingenieros de software a pasar una parte de su tiempo de
100
+
trabajo centrado en el Trabajo Ascendente, que se define como revisar
101
+
parches, servir en los comités de programas, mejorar la infraestructura
102
+
del proyecto central como escribir o mantener pruebas, reducir la deuda
103
+
de tecnología upstream, escribir documentación, etc.
104
+
* Los ingenieros de software son apoyados para ayudar a organizar
105
+
conferencias relacionadas con Linux.
106
+
* Las organizaciones considerarán los comentarios de los miembros de la
107
+
comunidad en las revisiones oficiales de rendimiento.
108
+
109
+
Nivel 5
110
+
=======
111
+
112
+
* El desarrollo del kernel upstream se considera un puesto de trabajo
113
+
formal, con al menos un tercio del tiempo del ingeniero pasado a hacer
114
+
el Trabajo Ascendente.
115
+
* Las organizaciones buscarán activamente las reacciones de los miembros
116
+
de la comunidad como un factor en las revisiones oficiales de
117
+
rendimiento.
118
+
* Las organizaciones informarán regularmente internamente sobre la ratio
119
+
de trabajo upstream a trabajo enfocado en perseguir directamente los
120
+
objetivos comerciales.