diff options
Diffstat (limited to 'documentation/content/es/articles/contributing/_index.adoc')
| -rw-r--r-- | documentation/content/es/articles/contributing/_index.adoc | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/documentation/content/es/articles/contributing/_index.adoc b/documentation/content/es/articles/contributing/_index.adoc index 1df4ddd068..4b5de262de 100644 --- a/documentation/content/es/articles/contributing/_index.adoc +++ b/documentation/content/es/articles/contributing/_index.adoc @@ -126,6 +126,24 @@ Las contribuciones al sistema generalmente pueden catalogarse en las siguientes Una idea o sugerencia técnica de interés _general_ se debería enviar a {freebsd-hackers}. Igualmente, gente con interés en esas cosas (¡y tolerancia para _altos_ volúmenes de correo!) pueden suscribirse a {freebsd-hackers}. Mira See extref:{handbook}[The FreeBSD Handbook, eresources-mail] para más información acerca de ésta y otras listas de correo. +Si estás enviando un parche sencillo al repositorio de src, por favor considera enviarlo a la réplica en el GitHub del proyecto en https://github.com/freebsd/freebsd-src/pulls[a pull request]. Un envío aceptable sería: + +* Está listo o casi listo para ser integrado. Un committer debería ser capaz de incluir este parche con menos de 10 minutos de trabajo adicional. +* Pasa todos los trabajos de CI en GitHub. +* Puedes responder a los comentarios rápidamente. +* Toca menos de unos 10 ficheros y los cambios son menos de 200 líneas. Cambios mayores podrían estar OK, o se te podría pedir que envíes varias pull requests de un tamaño más manejable. +* Cada cambio lógico está en un commit separado dentro de la pull request. Los mensajes de commit para cada cambio deberían seguir la extref:{committers-guide}#commit-log-message[guía de logs de commits]. +* Todos los commits tienen tu nombre y una dirección de correo electrónico válida tal y como te gustaría que aparecieran en el repositorio de FreeBSD al mostrar el autor. No se pueden usar cuentas github.com falsas. +* El alcance de la pull request no debería cambiar durante la revisión. Si en la revisión se sugieren cambios que amplían el alcance, por favor crea una pull request independiente. +* Los commits con arreglos se deberían agrupar junto al commit que arreglan. Cada commit en tu rama debería ser adecuado para el repositorio FreeBSD. +* Los commits deberían incluir una o más líneas `Signed-off-by:` con el nombre completo y dirección de correo electrónico cumpliendo el https://developercertificate.org/[Certificado de Origen del Desarrollador]. + +Cuando se actualice una pull request, por favor rebasa con un push forzado en lugar de hacer un commit tipo merge. Cambios más complejos se pueden enviar como pull requests, pero podrían cerrarse si son demasiado grandes, difíciles de manejar, necesitan discutirse con la comunidad, o necesitan una revisión amplia. Por favor evita crear parches grandes, que abarquen mucho: son demasiado grandes y carecen del foco necesario para una buena revisión. Los parches que estén mal dirigidos podrían ser reenviados a un foro más apropiado para que puedan ser resueltos. + +Las pull requests enviadas al respositorio de ports podrían ser o no atendidas, dependiendo de los desarrolladores. Por ahora, tendrás una mejor experiencia y sigues el proceso de envío de ports <<ports-contributing>>. + +El equipo de documentación también acepta requests vía GitHub, pero todavía no ha establecido ninguna política al respecto. + Si encuentras un fallo estás enviando un cambio específico, por favor repórtalo utilizando el https://bugs.FreeBSD.org/submit/[formulario de envío de errores]. Intenta rellenar cada uno de los campos del informe de error. A menos que excedan 65KB, incluye cualquier parche directamente en el reporte. Si el parche puede ser aplicado sobre el árbol de fuentes, pon `[PATCH]`en la sinopsis del informe. Cuando incluyas parches, _no_ utilices copiar y pegar porque copiar y pegar convierte tabuladores en espacios y los hace inutilizables. Cuando los parches son mucho mayores que 20KB, considera comprimirlos (ej. con man:gzip[1] o man:bzip2[1]) antes de subirlos. Tras rellenar el informe debería recibir un mensaje de confirmación junto con un número de seguimiento. Conserve este número de seguimiento para que pueda informarnos con nuevos detalles sobre el problema. |