Tema: collaboration
-
Un día programado de documentación atrae a más contribuyentes primerizos que una convocatoria permanente de ayuda con la documentación
Hipótesis: un proyecto que anuncia un único día con una lista seleccionada de incidencias pequeñas de documentación, personas mantenedoras disponibles para revisión el mismo día y una etiqueta de good-first-issue en cada tarea recibe más cambios de documentación fusionados de personas que nunca habían contribuido que la misma lista dejada abierta todo el año; una comparación propuesta sobre el propio historial de un proyecto.
-
Describir un cambio para que quienes lo revisan puedan revisarlo
Una descripción de cambio expone el problema, el enfoque y sus alternativas, cómo se probó y qué debería mirar quien revisa; enlaza el ticket y enumera riesgos y trabajo pendiente, de modo que la revisión empiece por la comprensión en lugar de por la arqueología.
-
Preferir propuestas de cambio para contenido de propiedad ajena
Mejorar el material de otra persona colaboradora mediante una propuesta vinculada a una revisión cuando no se está autorizado a reemplazarlo directamente.
-
Triaje de issues para un proyecto pequeño: un conjunto fijo de etiquetas y una pasada regular
Hacer triaje significa decidir, para cada issue nueva, qué es, si es accionable y quién actúa a continuación. Un vocabulario de etiquetas pequeño en tres familias (tipo, estado, área) más una pasada breve a un ritmo fijo mantiene honesto el tracker; las etiquetas por defecto de GitHub (entre ellas bug, enhancement, documentation, duplicate, question, wontfix, good first issue y help wanted) son un conjunto inicial funcional.
-
Reconocimiento de colaboradores: una tabla de colaboradores por tipo de contribución, sin clasificaciones
La especificación All Contributors exige una sección de colaboradores en un lugar destacado, en forma de tabla con nombre, enlace y categoría de contribución, que incluya todo tipo de contribución en cualquier nivel, sin que el orden importe; recomienda no excluir a nadie por un nivel de contribución percibido como bajo. El trailer Co-authored-by de Git reconoce a los coautores de un único commit. Juntos permiten que un proyecto pequeño reconozca la documentación, el triage, el diseño y los informes, no solo el código fusionado.
-
Un archivo CONTRIBUTING que responde las cinco primeras preguntas de quien llega al proyecto
Antes de escribir código, quien podría contribuir se pregunta: ¿se desea este cambio?, ¿cómo se propone?, ¿qué debe contener un pull request?, ¿cuánto tiempo pasará hasta obtener respuesta? y ¿cómo llega un cambio fusionado a las personas usuarias? Un archivo CONTRIBUTING que responda estas cinco preguntas en orden, y enlace a lo demás, busca evitar pull requests que acabarían rechazados por alcance o por falta de pruebas.
-
Rechazar una solicitud de funcionalidad sin perder a quien la propuso
Un rechazo que remite a un alcance escrito, llega con prontitud, indica una alternativa y cierra el hilo es más amable que el silencio, y mantiene a quien lo solicitó como colaborador. Las Open Source Guides señalan que dejar las cosas por escrito facilita decir que no, y que una respuesta rara vez necesita más de una o dos frases.
Legible por máquina: JSON