Tema: open-source
-
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.
-
Tras la llegada de un informe de vulnerabilidad: acusar recibo, evaluar, corregir en privado, divulgar
Una vez que un informe llega al contacto de seguridad del proyecto, el trabajo es una secuencia con fechas: acusar recibo con rapidez, clasificar (funciona como se espera, error, solicitud de función, vulnerabilidad), acordar un embargo con quien reporta, desarrollar la corrección en privado, obtener un identificador CVE y luego publicar y difundir un aviso que nombre las versiones afectadas y corregidas y reconozca a quien reportó. La guía para mantenedores de la OpenSSF y las indicaciones de divulgación de GitHub describen este proceso; este artículo lo resume para un proyecto con entre uno y cinco mantenedores.
-
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.
-
Cadencia de publicación para un proyecto pequeño: trenes basados en tiempo frente a publicar cuando esté listo
Un número de versión indica qué promete una publicación; una política de cadencia indica cuándo ocurren las publicaciones. Rust publica una versión estable cada seis semanas a partir de un tren nightly, beta, stable; Python pasó a una publicación anual de funcionalidades con la PEP 602, y Django emite publicaciones de funcionalidades según un calendario basado en tiempo, con publicaciones de parches según se necesiten. Un proyecto pequeño puede copiar esa forma: publicaciones de funcionalidades según un calendario o cuando se acumula algo notable, publicaciones de parches cada vez que se aplica una corrección.
-
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.
-
Deprecar una función en una biblioteca: avisar, documentar el reemplazo, retirar según calendario
Una deprecación de biblioteca tiene cuatro partes: un reemplazo que existe primero, un aviso en tiempo de ejecución más una nota de documentación que indica la versión y el reemplazo, una entrada en el registro de cambios, y una versión de eliminación fijada de antemano por política. PEP 387 exige un período de deprecación de al menos dos años bajo el ciclo anual de Python y describe una deprecación suave solo en la documentación; Django no elimina los adaptadores antes de dos versiones de funcionalidad posteriores al aviso.
-
Los repositorios cuya configuración se ejecuta como un único comando verificado reciben más contribuciones de primera vez que los repositorios con una lista de configuración manual
Hipótesis: el README de scripts-to-rule-them-all de GitHub sostiene que reducir la fricción de configuración es clave para contribuciones más rápidas y satisfactorias; la propuesta reformula esto de manera medible, prediciendo que los repositorios con un único comando de configuración que se autoverifica muestran más pull requests de contribuyentes primerizos, una mayor proporción de ellas en verde desde el primer push, y menos incidencias de configuración que repositorios comparables con pasos manuales en el README.
-
Gobernanza para un proyecto pequeño: derechos de decisión por escrito antes de necesitarlos
Un archivo de gobernanza responde quién puede fusionar cambios, quién resuelve una disputa de alcance, cómo se añaden y se retiran mantenedores y cómo se modifican las propias reglas. La PEP 13 de Python muestra un modelo de consejo cuya autoridad debe ejercerse pocas veces y con deliberación pública; el glosario de Apache define el consenso perezoso (lazy consensus), por el que una propuesta se aprueba si nadie objeta en un plazo establecido. Un proyecto con uno a tres mantenedores solo necesita una página.
-
¿En qué invierten realmente su tiempo los mantenedores de proyectos pequeños y qué hizo que el reparto se alejara de la escritura de código?
Pregunta abierta: las Open Source Guides señalan que los mantenedores de proyectos muy usados acaban programando menos y respondiendo más a issues, y recomiendan como remedios documentar, saber decir que no, repartir la carga y automatizar; faltan mediciones del tiempo por actividad en proyectos pequeños y pruebas de cuál de esos remedios modificó el reparto.
-
Traspaso de mantenedor y factor autobús: qué debe poder hacer un sucesor desde el primer día
Un proyecto sobrevive a su mantenedor cuando una segunda persona ya tiene todas las cuentas y claves, puede hacer una release solo con los pasos escritos y sabe dónde se registran las decisiones. PEP 541 muestra qué ocurre si no es así en PyPI: un proyecto se considera abandonado solo si el propietario no responde, no ha habido ninguna release en doce meses y su página de inicio no muestra actividad; solo entonces puede pasar a un nuevo propietario según la regla de abandono. La transferencia de repositorios de GitHub traslada issues, pull requests, estrellas y watchers junto con el código.
-
Mantener varias líneas de versiones: qué correcciones van a cada una
Una política de soporte es una tabla de líneas de versiones, cada una con un estado (desarrollo de funcionalidades, corrección de errores, solo seguridad, fin de vida), y una regla que indica qué clases de correcciones se portan a cada línea. Python mantiene una serie con versiones de corrección de errores durante dos años y versiones solo de seguridad durante tres más; Django porta las correcciones críticas a la última versión de funcionalidades y las de seguridad y pérdida de datos a las dos últimas más las líneas de soporte a largo plazo; Rust solo da soporte a la última versión estable. Un proyecto pequeño debería publicar la tabla y adoptar por defecto la promesa más acotada que pueda cumplir.
-
Código abierto en IBM i: yum, bash como shell predeterminada e inicio del daemon SSH
La pila de código abierto con soporte de IBM para IBM i (Node.js, Python, git, bash y más) se instala como RPM en /QOpenSys/pkgs mediante yum, incluye bash como shell interactiva recomendada y requiere iniciar explícitamente el daemon SSH con STRTCPSVR *SSHD antes de poder acceder a ella de forma remota.
Legible por máquina: JSON