docs/sp_SP: Add translation of process/researcher-guidelines

  From: Avadhut Naik <Avadhut.Naik@amd.com>

Translate Documentation/process/researcher-guidelines.rst into Spanish

Signed-off-by: Avadhut Naik <avadhut.naik@amd.com>
Reviewed-By: Carlos Bilbao <carlos.bilbao@amd.com>
---
 .../translations/sp_SP/process/index.rst      |   1 +
 .../sp_SP/process/researcher-guidelines.rst   | 152 ++++++++++++++++++
 2 files changed, 153 insertions(+)
 create mode 100644 Documentation/translations/sp_SP/process/researcher-guidelines.rst
  

On 6/19/23 2:27 PM, Avadhut Naik wrote:
> From: Avadhut Naik <Avadhut.Naik@amd.com>
> 
> Translate Documentation/process/researcher-guidelines.rst into Spanish
> 
> Signed-off-by: Avadhut Naik <avadhut.naik@amd.com>
> Reviewed-By: Carlos Bilbao <carlos.bilbao@amd.com>
> ---
>  .../translations/sp_SP/process/index.rst      |   1 +
>  .../sp_SP/process/researcher-guidelines.rst   | 152 ++++++++++++++++++
>  2 files changed, 153 insertions(+)
>  create mode 100644 Documentation/translations/sp_SP/process/researcher-guidelines.rst
> 
> diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documentation/translations/sp_SP/process/index.rst
> index 0bdeb1eb4403..ed6851892661 100644
> --- a/Documentation/translations/sp_SP/process/index.rst
> +++ b/Documentation/translations/sp_SP/process/index.rst
> @@ -20,3 +20,4 @@
>     programming-language
>     deprecated
>     adding-syscalls
> +   researcher-guidelines
> diff --git a/Documentation/translations/sp_SP/process/researcher-guidelines.rst b/Documentation/translations/sp_SP/process/researcher-guidelines.rst
> new file mode 100644
> index 000000000000..32d1810733e4
> --- /dev/null
> +++ b/Documentation/translations/sp_SP/process/researcher-guidelines.rst
> @@ -0,0 +1,152 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +:Original: :ref:`Documentation/process/researcher-guidelines.rst`
> +:Translator: Avadhut Naik <avadhut.naik@amd.com>
> +
> +.. _sp_researcher_guidelines:
> +
> +Directrices para Investigadores
> +++++++++++++++++++++++++++++++++
> +
> +La comunidad del kernel de Linux da la bienvenida a la investigación
> +transparente sobre el kernel de Linux, las actividades involucradas
> +en su producción, otros subproductos de su desarrollo. Linux se
> +beneficia mucho de este tipo de investigación, y la mayoría de los
> +aspectos de Linux son impulsados por investigación en una forma o otra.

s/una forma o otra/una forma u otra

> +
> +La comunidad agradece mucho si los investigadores pueden compartir
> +los hallazgos preliminares antes de hacer públicos sus resultados,
> +especialmente si tal investigación involucra seguridad. Involucrarse
> +temprano ayuda a mejorar la calidad de investigación y la capacidad
> +de Linux para mejorar a partir de ella. En cualquier caso, se recomienda
> +compartir copias de acceso abierto de la investigación publicada con
> +la comunidad.
> +
> +Este documento busca clarificar lo que la comunidad del kernel de Linux
> +considera practicas aceptables y no aceptables al llevar a cabo
> +investigación de este tipo. Por lo menos, dicha investigación y
> +actividades afines deben seguir las reglas estándar de ética de la
> +investigación. Para más información sobre la ética de la investigación
> +en general, ética en la tecnología y la investigación de las comunidades
> +de desarrolladores en particular, ver:
> +
> +
> +* `Historia de la Ética en la Investigación <https://www.unlv.edu/research/ORI-HSR/history-ethics>`_
> +* `Ética de la IEEE <https://www.ieee.org/about/ethics/index.html>`_
> +* `Perspectivas de Desarrolladores e Investigadores sobre la Ética de los Experimentos en Proyectos de Código Abierto <https://arxiv.org/pdf/2112.13217.pdf>`_
> +
> +La comunidad del kernel de Linux espera que todos los que interactúan con
> +el proyecto están participando en buena fe para mejorar Linux. La
> +investigación sobre cualquier artefacto disponible públicamente (incluido,
> +pero no limitado a código fuente) producido por la comunidad del kernel
> +de Linux es bienvenida, aunque la investigación sobre los desarrolladores
> +debe ser claramente opcional.
> +
> +La investigación pasiva que se basa completamente en fuentes disponibles
> +públicamente, incluidas las publicaciones en listas de correo públicas y
> +las contribuciones a los repositorios públicos, es claramente permitida.
> +Aunque, como con cualquier investigación, todavía se debe seguir la ética
> +estándar.
> +
> +La investigación activa sobre el comportamiento de los desarrolladores,
> +sin embargo, debe hacerse con el acuerdo explícito y la divulgación
> +completa a los desarrolladores individuales involucrados. No se puede
> +interactuar / experimentar con los desarrolladores sin consentimiento;
> +esto también es ética de investigación estándar.
> +
> +Para ayudar a aclarar: enviar parches a los desarrolladores es interactuar
> +con ellos, pero ya han dado su consentimiento para recibir contribuciones
> +en buena fe. No se ha dado consentimiento para enviar parches intencionalmente
> +defectuosos / vulnerables o contribuir con la información engañosa a las
> +discusiones. Dicha comunicación puede ser perjudicial al desarrollador (por
> +ejemplo, agotar el tiempo, el esfuerzo, y la moral) y perjudicial para el
> +proyecto al erosionar la confianza de toda la comunidad de desarrolladores en
> +el colaborador (y la organización del colaborador en conjunto), socavando
> +los esfuerzos para proporcionar reacciones constructivas a los colaboradores
> +y poniendo a los usuarios finales en riesgo de fallas de software.
> +
> +La participación en el desarrollo de Linux en sí mismo por parte de
> +investigadores, como con cualquiera, es bienvenida y alentada. La
> +investigación del código de Linux es una práctica común, especialmente
> +cuando se trata de desarrollar o ejecutar herramientas de análisis que
> +producen resultados procesables.
> +
> +Cuando se interactúa con la comunidad de desarrolladores, enviar un
> +parche ha sido tradicionalmente la mejor manera para hacer un impacto.
> +Linux ya tiene muchos errores conocidos – lo que es mucho más útil es
> +tener soluciones verificadas. Antes de contribuir, lea cuidadosamente
> +la documentación adecuada.
> +
> +* Documentation/process/development-process.rst
> +* Documentation/process/submitting-patches.rst
> +* Documentation/admin-guide/reporting-issues.rst
> +* Documentation/process/security-bugs.rst
> +
> +Entonces envíe un parche (incluyendo un registro de confirmación con
> +todos los detalles enumerados abajo) y haga un seguimiento de cualquier
> +comentario de otros desarrolladores.
> +
> +* ¿Cuál es el problema específico que se ha encontrado?
> +* ¿Como podría llegar al problema en un sistema en ejecución?
> +* ¿Qué efecto tendría encontrar el problema en el sistema?
> +* ¿Como se encontró el problema? Incluya específicamente detalles sobre
> +  cualquier prueba, programas de análisis estáticos o dinámicos, y cualquier
> +  otra herramienta o método utilizado para realizar el trabajo.
> +* ¿En qué versión de Linux se encontró el problema? Se prefiere usar la
> +  versión más reciente o una rama reciente de linux-next (ver
> +  Documentation/process/howto.rst).
> +* ¿Que se cambió para solucionar el problema y por qué se cree es correcto?
> +* ¿Como se probó el cambio para la complicación y el tiempo de ejecución?
> +* ¿Qué confirmación previa corrige este cambio? Esto debería ir en un “Fixes:”
> +  etiqueta como se describe en la documentación.
> +* ¿Quién más ha revisado este parche? Esto debería ir con la adecuada “Reviewed-by”
> +  etiqueta; Vea abajo.
> +
> +For example::

s/For example/Por ejemplo (en inglés, pues es en las listas):

> +
> +  From: Author <author@email>
> +  Subject: [PATCH] drivers/foo_bar: Add missing kfree()
> +
> +  The error path in foo_bar driver does not correctly free the allocated
> +  struct foo_bar_info. This can happen if the attached foo_bar device
> +  rejects the initialization packets sent during foo_bar_probe(). This
> +  would result in a 64 byte slab memory leak once per device attach,
> +  wasting memory resources over time.
> +
> +  This flaw was found using an experimental static analysis tool we are
> +  developing, LeakMagic[1], which reported the following warning when
> +  analyzing the v5.15 kernel release:
> +
> +   path/to/foo_bar.c:187: missing kfree() call?
> +
> +  Add the missing kfree() to the error path. No other references to
> +  this memory exist outside the probe function, so this is the only
> +  place it can be freed.
> +
> +  x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC
> +  11.2 show no new warnings, and LeakMagic no longer warns about this
> +  code path. As we don't have a FooBar device to test with, no runtime
> +  testing was able to be performed.
> +
> +  [1] https://url/to/leakmagic/details
> +
> +  Reported-by: Researcher <researcher@email>
> +  Fixes: aaaabbbbccccdddd ("Introduce support for FooBar")
> +  Signed-off-by: Author <author@email>
> +  Reviewed-by: Reviewer <reviewer@email>
> +
> +Si usted es un colaborador por primera vez, se recomienda que el parche en
> +si sea examinado por otros en privado antes de ser publicado en listas
> +públicas. (Esto es necesario si se le ha dicho explícitamente que sus parches
> +necesitan una revisión interna más cuidadosa.) Se espera que estas personas
> +tengan su etiqueta “Reviewed-by” incluida en el parche resultante. Encontrar
> +otro desarrollador con conocimiento de las contribuciones a Linux, especialmente
> +dentro de su propia organización, y tener su ayuda con las revisiones antes de
> +enviarlas a las listas de correo publico tiende a mejorar significativamente la
> +calidad de los parches resultantes, y reduce así la carga de otros desarrolladores.
> +
> +Si no se puede encontrar a nadie para revisar internamente los parches y necesita
> +ayuda para encontrar a esa persona, o si tiene alguna otra pregunta relacionada
> +con este documento y las expectativas de la comunidad de desarrolladores, por
> +favor contacte con la lista de correo privada Technical Advisory Board:
> +<tech-board@lists.linux-foundation.org>.

Other than that, my Reviewed-By stays :) thanks Avadhut!

Best,
Carlos
  

Hi,
	Thanks for reviewing.

On 6/20/2023 08:40, Carlos Bilbao wrote:
> On 6/19/23 2:27 PM, Avadhut Naik wrote:
>> From: Avadhut Naik <Avadhut.Naik@amd.com>
>>
>> Translate Documentation/process/researcher-guidelines.rst into Spanish
>>
>> Signed-off-by: Avadhut Naik <avadhut.naik@amd.com>
>> Reviewed-By: Carlos Bilbao <carlos.bilbao@amd.com>
>> ---
>>  .../translations/sp_SP/process/index.rst      |   1 +
>>  .../sp_SP/process/researcher-guidelines.rst   | 152 ++++++++++++++++++
>>  2 files changed, 153 insertions(+)
>>  create mode 100644 Documentation/translations/sp_SP/process/researcher-guidelines.rst
>>
>> diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documentation/translations/sp_SP/process/index.rst
>> index 0bdeb1eb4403..ed6851892661 100644
>> --- a/Documentation/translations/sp_SP/process/index.rst
>> +++ b/Documentation/translations/sp_SP/process/index.rst
>> @@ -20,3 +20,4 @@
>>     programming-language
>>     deprecated
>>     adding-syscalls
>> +   researcher-guidelines
>> diff --git a/Documentation/translations/sp_SP/process/researcher-guidelines.rst b/Documentation/translations/sp_SP/process/researcher-guidelines.rst
>> new file mode 100644
>> index 000000000000..32d1810733e4
>> --- /dev/null
>> +++ b/Documentation/translations/sp_SP/process/researcher-guidelines.rst
>> @@ -0,0 +1,152 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>> +:Original: :ref:`Documentation/process/researcher-guidelines.rst`
>> +:Translator: Avadhut Naik <avadhut.naik@amd.com>
>> +
>> +.. _sp_researcher_guidelines:
>> +
>> +Directrices para Investigadores
>> +++++++++++++++++++++++++++++++++
>> +
>> +La comunidad del kernel de Linux da la bienvenida a la investigación
>> +transparente sobre el kernel de Linux, las actividades involucradas
>> +en su producción, otros subproductos de su desarrollo. Linux se
>> +beneficia mucho de este tipo de investigación, y la mayoría de los
>> +aspectos de Linux son impulsados por investigación en una forma o otra.
> 
> s/una forma o otra/una forma u otra
> 
>> +
>> +La comunidad agradece mucho si los investigadores pueden compartir
>> +los hallazgos preliminares antes de hacer públicos sus resultados,
>> +especialmente si tal investigación involucra seguridad. Involucrarse
>> +temprano ayuda a mejorar la calidad de investigación y la capacidad
>> +de Linux para mejorar a partir de ella. En cualquier caso, se recomienda
>> +compartir copias de acceso abierto de la investigación publicada con
>> +la comunidad.
>> +
>> +Este documento busca clarificar lo que la comunidad del kernel de Linux
>> +considera practicas aceptables y no aceptables al llevar a cabo
>> +investigación de este tipo. Por lo menos, dicha investigación y
>> +actividades afines deben seguir las reglas estándar de ética de la
>> +investigación. Para más información sobre la ética de la investigación
>> +en general, ética en la tecnología y la investigación de las comunidades
>> +de desarrolladores en particular, ver:
>> +
>> +
>> +* `Historia de la Ética en la Investigación <https://www.unlv.edu/research/ORI-HSR/history-ethics>`_
>> +* `Ética de la IEEE <https://www.ieee.org/about/ethics/index.html>`_
>> +* `Perspectivas de Desarrolladores e Investigadores sobre la Ética de los Experimentos en Proyectos de Código Abierto <https://arxiv.org/pdf/2112.13217.pdf>`_
>> +
>> +La comunidad del kernel de Linux espera que todos los que interactúan con
>> +el proyecto están participando en buena fe para mejorar Linux. La
>> +investigación sobre cualquier artefacto disponible públicamente (incluido,
>> +pero no limitado a código fuente) producido por la comunidad del kernel
>> +de Linux es bienvenida, aunque la investigación sobre los desarrolladores
>> +debe ser claramente opcional.
>> +
>> +La investigación pasiva que se basa completamente en fuentes disponibles
>> +públicamente, incluidas las publicaciones en listas de correo públicas y
>> +las contribuciones a los repositorios públicos, es claramente permitida.
>> +Aunque, como con cualquier investigación, todavía se debe seguir la ética
>> +estándar.
>> +
>> +La investigación activa sobre el comportamiento de los desarrolladores,
>> +sin embargo, debe hacerse con el acuerdo explícito y la divulgación
>> +completa a los desarrolladores individuales involucrados. No se puede
>> +interactuar / experimentar con los desarrolladores sin consentimiento;
>> +esto también es ética de investigación estándar.
>> +
>> +Para ayudar a aclarar: enviar parches a los desarrolladores es interactuar
>> +con ellos, pero ya han dado su consentimiento para recibir contribuciones
>> +en buena fe. No se ha dado consentimiento para enviar parches intencionalmente
>> +defectuosos / vulnerables o contribuir con la información engañosa a las
>> +discusiones. Dicha comunicación puede ser perjudicial al desarrollador (por
>> +ejemplo, agotar el tiempo, el esfuerzo, y la moral) y perjudicial para el
>> +proyecto al erosionar la confianza de toda la comunidad de desarrolladores en
>> +el colaborador (y la organización del colaborador en conjunto), socavando
>> +los esfuerzos para proporcionar reacciones constructivas a los colaboradores
>> +y poniendo a los usuarios finales en riesgo de fallas de software.
>> +
>> +La participación en el desarrollo de Linux en sí mismo por parte de
>> +investigadores, como con cualquiera, es bienvenida y alentada. La
>> +investigación del código de Linux es una práctica común, especialmente
>> +cuando se trata de desarrollar o ejecutar herramientas de análisis que
>> +producen resultados procesables.
>> +
>> +Cuando se interactúa con la comunidad de desarrolladores, enviar un
>> +parche ha sido tradicionalmente la mejor manera para hacer un impacto.
>> +Linux ya tiene muchos errores conocidos – lo que es mucho más útil es
>> +tener soluciones verificadas. Antes de contribuir, lea cuidadosamente
>> +la documentación adecuada.
>> +
>> +* Documentation/process/development-process.rst
>> +* Documentation/process/submitting-patches.rst
>> +* Documentation/admin-guide/reporting-issues.rst
>> +* Documentation/process/security-bugs.rst
>> +
>> +Entonces envíe un parche (incluyendo un registro de confirmación con
>> +todos los detalles enumerados abajo) y haga un seguimiento de cualquier
>> +comentario de otros desarrolladores.
>> +
>> +* ¿Cuál es el problema específico que se ha encontrado?
>> +* ¿Como podría llegar al problema en un sistema en ejecución?
>> +* ¿Qué efecto tendría encontrar el problema en el sistema?
>> +* ¿Como se encontró el problema? Incluya específicamente detalles sobre
>> +  cualquier prueba, programas de análisis estáticos o dinámicos, y cualquier
>> +  otra herramienta o método utilizado para realizar el trabajo.
>> +* ¿En qué versión de Linux se encontró el problema? Se prefiere usar la
>> +  versión más reciente o una rama reciente de linux-next (ver
>> +  Documentation/process/howto.rst).
>> +* ¿Que se cambió para solucionar el problema y por qué se cree es correcto?
>> +* ¿Como se probó el cambio para la complicación y el tiempo de ejecución?
>> +* ¿Qué confirmación previa corrige este cambio? Esto debería ir en un “Fixes:”
>> +  etiqueta como se describe en la documentación.
>> +* ¿Quién más ha revisado este parche? Esto debería ir con la adecuada “Reviewed-by”
>> +  etiqueta; Vea abajo.
>> +
>> +For example::
> 
> s/For example/Por ejemplo (en inglés, pues es en las listas):
> 
>> +
>> +  From: Author <author@email>
>> +  Subject: [PATCH] drivers/foo_bar: Add missing kfree()
>> +
>> +  The error path in foo_bar driver does not correctly free the allocated
>> +  struct foo_bar_info. This can happen if the attached foo_bar device
>> +  rejects the initialization packets sent during foo_bar_probe(). This
>> +  would result in a 64 byte slab memory leak once per device attach,
>> +  wasting memory resources over time.
>> +
>> +  This flaw was found using an experimental static analysis tool we are
>> +  developing, LeakMagic[1], which reported the following warning when
>> +  analyzing the v5.15 kernel release:
>> +
>> +   path/to/foo_bar.c:187: missing kfree() call?
>> +
>> +  Add the missing kfree() to the error path. No other references to
>> +  this memory exist outside the probe function, so this is the only
>> +  place it can be freed.
>> +
>> +  x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC
>> +  11.2 show no new warnings, and LeakMagic no longer warns about this
>> +  code path. As we don't have a FooBar device to test with, no runtime
>> +  testing was able to be performed.
>> +
>> +  [1] https://url/to/leakmagic/details
>> +
>> +  Reported-by: Researcher <researcher@email>
>> +  Fixes: aaaabbbbccccdddd ("Introduce support for FooBar")
>> +  Signed-off-by: Author <author@email>
>> +  Reviewed-by: Reviewer <reviewer@email>
>> +
>> +Si usted es un colaborador por primera vez, se recomienda que el parche en
>> +si sea examinado por otros en privado antes de ser publicado en listas
>> +públicas. (Esto es necesario si se le ha dicho explícitamente que sus parches
>> +necesitan una revisión interna más cuidadosa.) Se espera que estas personas
>> +tengan su etiqueta “Reviewed-by” incluida en el parche resultante. Encontrar
>> +otro desarrollador con conocimiento de las contribuciones a Linux, especialmente
>> +dentro de su propia organización, y tener su ayuda con las revisiones antes de
>> +enviarlas a las listas de correo publico tiende a mejorar significativamente la
>> +calidad de los parches resultantes, y reduce así la carga de otros desarrolladores.
>> +
>> +Si no se puede encontrar a nadie para revisar internamente los parches y necesita
>> +ayuda para encontrar a esa persona, o si tiene alguna otra pregunta relacionada
>> +con este documento y las expectativas de la comunidad de desarrolladores, por
>> +favor contacte con la lista de correo privada Technical Advisory Board:
>> +<tech-board@lists.linux-foundation.org>.
> 
> Other than that, my Reviewed-By stays :) thanks Avadhut!
> 
	ACK to all suggestions. Will incorporate and resubmit.

Thanks,
Avadhut Naik

> Best,
> Carlos

--