Skip to content

Latest commit

 

History

History
51 lines (38 loc) · 4.34 KB

CONTRIBUTING.md

File metadata and controls

51 lines (38 loc) · 4.34 KB

¿Cómo contribuir en este proyecto?

Existen muchas maneras de contribuir con Cloud Security Ninja. Escribir contenido para la página web, mantener la información contenida actualizada, detectar problemas o corregirlos son formas efectivas de mejorar la comunidad.

Recuerda que, tanto contribuir a este repositorio como administrarlo, supone la aceptación de nuestro código de conducta.

Informando un problema

La forma más sencilla de contribuir con la página web es informar de un error detectado. Introduce un título corto y, en el espacio para comentarios, indica la dirección web donde detectaste el problema, y añade una pequeña descripción del mismo. Recuerda que puedes añadir imágenes, como capturas de pantalla, arrastrando la imagen sobre el editor.

Estrategias efectivas para la redacción de artículos técnicos

Esta guía para contribuidores tiene por objetivo que todos quienes redactemos contenido para esta plataforma, sigamos una semámtica clara y ordenada.

Cantidad de palabras

  • Artículos de introducción o generales: 800-1200 palabras.
  • Artículos detallados y técnicos: 1500-2500 palabras.

Esto depende del alcance y la complejidad del tema. Sin embargo, el objetivo debe ser siempre proporcionar un valor sustancial al lector.

Punto de vista

  • Primera persona ("Yo"): Esto puede hacer que el artículo sea más personal y relatable. Es especialmente útil si estás compartiendo experiencias personales u opiniones.
  • Tercera persona ("Se debe hacer", "los usuarios pueden"): Esto da un tono más formal y puede ser más apropiado para artículos puramente técnicos o instructivos.

Uso de Referencias

  • Citar estudios, estadísticas, y referencias técnicas para validar tus puntos.
  • Cuando hagas afirmaciones técnicas, es útil apuntar a la documentación oficial o papers relevantes.
  • Asegúrate de dar crédito a las fuentes y, si es posible, incluir enlaces a la información original.

Estructura Sugerida

  • Introducción: Presenta el problema o el tema central.
  • Contexto o Fundamento: Proporciona información de fondo necesaria.
  • Cuerpo Principal: Desglosa la solución o el tema en subsecciones.
  • Ejemplos prácticos: Específicamente en AWS, mostrar ejemplos de código o configuraciones puede ser muy valioso.
  • Conclusión: Resumen y próximos pasos.
  • Referencias: Lista de todas las fuentes citadas.

Estilo y tono

  • Utiliza un lenguaje claro y conciso.
  • Evita el uso excesivo de jerga técnica a menos que sea absolutamente necesario.
  • Puedes utilizar imágenes, gráficos o tablas para ilustrar puntos complejos.

Manteniendo el sitio web

Otra forma de contribuir con este proyecto es echando un vistazo a las issues abiertas, escoger una y solucionarla.

¿Qué pasa si no tengo perfil técnico? ¿Puedo contribuir?

Si, puedes mejorar los ficheros README.md y CONTRIBUTING.md para que pueda ser entendible por todo tipo de perfil, a lo mejor mientras redacto estos ficheros, lo estoy haciendo desde un punto de vista muy técnico. Utiliza el mismo procedimiento explicado en la sección Editando contenido ya existente para proponer cambios en estos ficheros.

Proceso de revisión

Cuando propongas algún cambio, GitHub creará un pull request. Un pull request es una petición en tu nombre, con las alteraciones propuestas, que permite discutir sobre las mismas. Se realizará una revisión de la petición y GitHub te irá notificando en tu correo electrónico conforme se añadan nuevos comentarios.

Atiende los cambios que te hayan pedido y discute respetuosamente aquellos en los que no estés de acuerdo, añadiendo tus propios comentarios (podrás utilizar la variante GitHub de Markdown para ello).

Solucionar los problemas de un pull request puede no ser el paso final. El proceso de revisión puede repetirse. Atiende las sucesivas revisiones y el equipo editorial aceptará tus cambios cuando todos los problemas se hayan resuelto.