El siguiente contenido es de MDN Web Docs: https://developer.mozilla.org/zh-CN/docs/MDN/Community/Open_source_etiquette
Etiqueta del proyecto de código abierto
Si nunca ha trabajado en un proyecto de código abierto (OSP), le recomendamos leer este artículo antes de comenzar a contribuir a la documentación web de MDN (u otros proyectos de código abierto). A continuación se presentan algunas de las mejores prácticas que puede implementar para ayudar a garantizar que usted y otros contribuyentes del proyecto se sientan valorados y seguros, y sigan siendo productivos.
Este artículo no le enseñará todos los trucos sobre cómo contribuir a proyectos de código abierto. El objetivo de este artículo es principalmente brindarle algunos buenos puntos de partida para contribuir a proyectos de código abierto.
¿Por qué deberías contribuir a un proyecto de código abierto?
Cuando empieces a contribuir a proyectos de código abierto, reflexiona sobre por qué estás haciendo esas contribuciones. Lo más probable es que tu respuesta sea "Estoy demasiado aburrido y quiero encontrar algo productivo para matar el tiempo." Está bien, pero en realidad puedes ir un paso más allá.
Las siguientes razones pueden ser mejores:
- Utilizo esta herramienta todo el tiempo y encuentro un error o necesito ayuda para resolverlo.
- Quiero ayudar a otros a utilizar esta herramienta con mayor facilidad.
- Quiero ayudar a otros a contribuir a los proyectos de forma más fluida.
- Quiero mejorar mi nivel de habilidad personal.
- Quería demostrar públicamente las habilidades que aprendí en los cursos universitarios.
- Quiero mostrar mis habilidades públicamente para aumentar mis posibilidades de conseguir un trabajo.
Algunas razones son "egoístas", y eso está bien. Si dedica algo de tiempo a un proyecto gratuito, espere ganar algo. Además, tener estas razones claras para contribuir le facilitará decidir con qué empezar primero.
Su presencia en el proyecto debe ser productiva y no debe impedir otros trabajos productivos.
Sea cortés y amigable y evite usar lenguaje incendiario u ofensivo.
En definitiva, se trata de "ser amable con los demás". Este es nuestro primer consejo para cualquiera que empiece a contribuir a un proyecto de código abierto.
Tratar bien a otros colaboradores del proyecto crea una atmósfera armoniosa y productiva. Esto incluye:
- Gracias a quienes os han ayudado.
- Felicite a las personas cuando sea apropiado (por ejemplo, completaron su primera solicitud de extracción o solucionaron un error difícil).
- Responda siempre a los demás con respeto, incluso si cree que la respuesta a la pregunta es obvia o si la persona que pregunta está duplicando su propio trabajo.
- Intente ayudar a las personas a trabajar mejor la próxima vez, por ejemplo, al revisar las solicitudes de extracción y responder preguntas, decir "esto está mal" o "esta es la respuesta necesaria" es mucho menos efectivo que decir "esto está bien, pero pensé que sería mejor". Si intenta algo como esto, aquí hay una publicación de blog que explica más ideas" o "Puede encontrar las respuestas aquí o consultar este enlace para obtener respuestas a las preguntas más frecuentes", que pueden resultarle útiles.
Usted y otros contribuyentes están (o deberían estar) aquí porque quieren hacer una contribución activa al proyecto, pero más allá de eso, no pueden hacer ninguna suposición sobre ellos, incluido su:
- Comprensión de los proyectos y las tecnologías utilizadas para construirlos.
- Género, orientación sexual, edad, idioma, ubicación, opiniones políticas, creencias religiosas u otros atributos personales.
- Experiencia participando en proyectos de código abierto.
- confianza
- Expectativas
- sentido del humor
Por lo tanto, debes asegurarte de que lo que escribas sea lo más relevante posible y se mantenga alejado de temas potencialmente controvertidos, como la religión o la política. Incluso si no está de acuerdo con el punto de vista de alguien o no le gusta la decisión que tomó, sea comprensivo y respetuoso.
Además, debe abstenerse de utilizar malas palabras y lenguaje ofensivo, incluso si no está dirigido específicamente a nadie. Esto no es un requisito para participar y algunas personas pueden ser bastante sensibles al respecto.
Es importante tener en cuenta que cualquier buen proyecto de código abierto tendrá reglas para proteger a sus contribuyentes de sentirse incómodos al contribuir. Esto suele aparecer en GitHub como un archivo CODE_OF_CONDUCT.md.
Por ejemplo, el código base de MDN se rige por las extensas Pautas de participación comunitaria de Mozilla . Por lo general, en el repositorio web de MDN, el comportamiento levemente ofensivo (como una discusión continua fuera de tema o un comportamiento disruptivo o un comportamiento grosero) recibirá una advertencia en el repositorio, luego una advertencia final y, finalmente, una prohibición temporal o permanente. No se tolerarán problemas de comportamiento más graves, como discursos de odio y amenazas a otros miembros contribuyentes, y pueden dar lugar a una prohibición inmediata.
Si recibes algún contenido que te incomode, siempre puedes denunciarlo utilizando los mecanismos mencionados en el código de conducta.
Elija una contribución válida
Averigua qué vas a hacer en el proyecto. Por ejemplo, tendremos una lista de problemas registrados en el panel de tareas del colaborador , que se muestran por separado según el tipo de tarea.
También puedes crear una solicitud de extracción para solucionar los problemas que detectes mientras lees un artículo de MDN.
Gran parte del trabajo en MDN gira en torno a la documentación y el código de muestra, pero también puedes contribuir de estas maneras:
- Categorizar los problemas.
- 错别字 modificado.
- Mejore la gramática para que el contenido de la página sea más fácil de entender.
- Instruya a las personas sobre cómo solucionarlo.
Cada solución es útil, por trivial que sea, y no la rechazaremos. Aún así, trate de asegurarse de que sus reparaciones sean efectivas. No recomendamos realizar este tipo de aportaciones:
- Actualiza el estilo del código a tu gusto.
- Actualiza los estilos de idioma a tu gusto.
- Cambie el inglés americano de la página a inglés británico.
- Agregue o elimine un lote de signos de puntuación sin ningún problema.
- Modifique el marco de prueba que estamos utilizando según sus preferencias.
En muchos casos, las cosas existen en proyectos de código abierto por una razón. Si tiene una guía de estilo, debes leerla; si tienes dudas sobre si algo es válido, ¡pregunta primero!
leer el manual
Los buenos proyectos de código abierto siempre hacen que la documentación de los contribuyentes esté disponible. Para los proyectos de GitHub, el contenido suele existir en el archivo CONTRIBUTING.md del repositorio o en el archivo README.md del proyecto. Como proyecto de documentación, el contenido de MDN tiene un archivo README y un conjunto completo de documentación del colaborador para el sitio mismo (consulte Contribución a la documentación web de MDN ).
No tenga miedo de pedir ayuda, pero trate siempre de encontrar las respuestas usted mismo antes de hacer preguntas. Esto le permite acumular conocimientos sobre el proyecto de forma independiente sin imponer una carga innecesaria a otros contribuyentes.
Por supuesto, la documentación no siempre es perfecta, y si es difícil encontrar una explicación o no se describe lo suficientemente bien, presente un problema o cree una solicitud de extracción para intentar solucionarlo usted mismo.
¿Dónde preguntar?
Averigüe siempre cuál es el mejor lugar para hacer preguntas. Los buenos proyectos de código abierto siempre especificarán esto claramente en su documentación (consulte la sección Cómo ponerse en contacto ). Si desea hacer preguntas generales, utilice estos canales. No todos los problemas son adecuados para los problemas de GitHub, y los problemas inapropiados pueden saturar el proyecto (consulte la sección "Avanzar, no ensuciar" a continuación).
progresa, no te metas
Piense detenidamente en la forma en que se comunica sobre el proyecto para asegurarse de que sea útil y no dificulte el trabajo de otros contribuyentes. Enviar solicitudes de extracción para corregir errores es fantástico, pero ¿son realmente útiles y revisables? Plantear problemas y unirse a otras conversaciones está bien, pero ¿sus problemas y comentarios se ajustan al tema o simplemente aumentan el desorden?
Normalmente, es necesario:
- Discuta solo un tema por tema para mantenerlo enfocado y efectivo.
- Solucione solo un problema por solicitud de extracción (PR): esto puede requerir un poco más de trabajo de su parte, pero es mucho más fácil revisar una solución clara.
- Si tiene un punto útil o puede responder la pregunta de otra persona, contribuya en otros hilos.
- Si no estás seguro de si algo es útil o tienes una pregunta sencilla, puedes utilizar otros mecanismos como salas de chat o foros para hacer una pregunta.
- Antes de hacer una pregunta, lea el manual e intente responderla usted mismo.
no quiero:
- Complicar el problema al intentar discutir varios temas a la vez o hacer comentarios fuera de tema.
- Incluir varias correcciones en una sola solicitud de extracción dificulta la revisión y genera sospechas (alguien puede estar intentando ocultar algún código malicioso entre los cambios válidos).
- Abra muchos temas y haga preguntas vagas.
- No intente resolver un problema usted mismo antes de preguntar.
Los proyectos de código abierto son (casi) democráticos
Los proyectos de código abierto son bastante democráticos, se votan muchas decisiones y eres libre de contribuir con lo que quieras siempre y cuando no obstaculices las contribuciones de otros.
Sin embargo, algunas cosas las decidirá principalmente un pequeño grupo central de contribuyentes. Usted es libre de presentar sus argumentos en contra de cualquier decisión, pero a veces los contribuyentes principales tomarán decisiones contrarias a su opinión y usted debe respetar y aceptar esas decisiones.
Es útil conocer a los principales contribuyentes de un proyecto para saber a quién pedir ayuda con cosas como solicitudes de extracción o hilos de problemas.
Sea paciente y rápido
Recuerde, muchas personas trabajan en proyectos de código abierto en su tiempo libre sin ingresos y, en general, las personas que trabajan en proyectos de código abierto están muy ocupadas. Si está esperando una revisión de una solicitud de extracción o una respuesta a una pregunta, tenga paciencia.
Lo razonable es esperar unos días y luego, educadamente, ponerse en contacto con alguien y preguntarle si tiene tiempo de verlo. Si están demasiado ocupados, es mejor esperar una semana más antes de intentar hacer un seguimiento con ellos.
No es razonable exigir algo desde el principio, como una respuesta rápida.
Si alguien está esperando que usted haga algo por él, debe recibir la misma cortesía, pero al mismo tiempo tratar de responder con prontitud. Si realmente no puede encontrar el tiempo, infórmeles y pida a los encargados de mantenimiento que le ayuden a encontrar a otra persona para completar la tarea.
ver