Translate Documentation/process/contribution-maturity-model.rst into
Spanish
Signed-off-by: Avadhut Naik <[email protected]>
Reviewed-by: Carlos Bilbao <[email protected]>
---
.../process/contribution-maturity-model.rst | 120 ++++++++++++++++++
.../translations/sp_SP/process/index.rst | 1 +
2 files changed, 121 insertions(+)
create mode 100644 Documentation/translations/sp_SP/process/contribution-maturity-model.rst
diff --git a/Documentation/translations/sp_SP/process/contribution-maturity-model.rst b/Documentation/translations/sp_SP/process/contribution-maturity-model.rst
new file mode 100644
index 000000000000..36a6f9727933
--- /dev/null
+++ b/Documentation/translations/sp_SP/process/contribution-maturity-model.rst
@@ -0,0 +1,120 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../disclaimer-sp.rst
+
+:Original: :ref:`Documentation/process/contribution-maturity-model.rst`
+:Translator: Avadhut Naik <[email protected]>
+
+====================================================
+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.
diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documentation/translations/sp_SP/process/index.rst
index ed6851892661..09bfece0f52f 100644
--- a/Documentation/translations/sp_SP/process/index.rst
+++ b/Documentation/translations/sp_SP/process/index.rst
@@ -21,3 +21,4 @@
deprecated
adding-syscalls
researcher-guidelines
+ contribution-maturity-model
--
2.34.1
Avadhut Naik <[email protected]> writes:
> Translate Documentation/process/contribution-maturity-model.rst into
> Spanish
>
> Signed-off-by: Avadhut Naik <[email protected]>
> Reviewed-by: Carlos Bilbao <[email protected]>
> ---
> .../process/contribution-maturity-model.rst | 120 ++++++++++++++++++
> .../translations/sp_SP/process/index.rst | 1 +
> 2 files changed, 121 insertions(+)
> create mode 100644 Documentation/translations/sp_SP/process/contribution-maturity-model.rst
>
> diff --git a/Documentation/translations/sp_SP/process/contribution-maturity-model.rst b/Documentation/translations/sp_SP/process/contribution-maturity-model.rst
> new file mode 100644
> index 000000000000..36a6f9727933
> --- /dev/null
> +++ b/Documentation/translations/sp_SP/process/contribution-maturity-model.rst
> @@ -0,0 +1,120 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +.. include:: ../disclaimer-sp.rst
> +
> +:Original: :ref:`Documentation/process/contribution-maturity-model.rst`
So that line creates this build warning:
> Documentation/translations/sp_SP/process/contribution-maturity-model.rst:4:
> WARNING: undefined label: documentation/process/contribution-maturity-model.rst
Please be sure to do a docs build and ensure that you're not adding
warnings before sending patches.
The fix in this case is to make the line read simply:
> :Original: Documentation/process/contribution-maturity-model.rst
...and all the right things happen. I've made that fix and applied the
patch this time.
Thanks,
jon