El desarrollador y consultor Mike Zornek comparte el sistema personal que aplica cuando tiene responsabilidad de gestión en un proyecto y margen para diseñar flujos de trabajo. El texto no plantea una metodología única, sino una forma concreta de trabajar que él mismo ha ido puliendo y que puede servir de referencia a equipos que quieran evolucionar sus propios procesos.
La pieza gira en torno a tres pilares. Primero, el seguimiento de tareas en GitHub Issues combinado con GitHub Projects para visualizar el avance y la planificación, con el objetivo deliberado de mantener el conocimiento junto al código en lugar de dispersarlo en herramientas externas. Segundo, una clasificación de estados más granular que la habitual —Oportunidades, En cola, En curso, Necesita revisión, Hecho (fusionado), Desplegado, Por verificar, Verificado y Cancelado— donde el uso del término "Oportunidades" en lugar de "Backlog" busca evitar la culpa implícita de una pila creciente. Acompañan a estos estados una serie de tipos de issue (Tarea, Error, Funcionalidad, Mejora, Seguridad, Refactorización, Documentación, etc.) pensados para navegar listas grandes.
En tercer lugar, Zornek detalla cómo enfoca los pull requests: vincularlos al issue correspondiente mediante palabras clave para que se cierren automáticamente al fusionarse, usar plantillas mínimas o más completas con listas de auto-revisión del autor, abrir los PR en estado borrador desde el inicio del desarrollo y mantenerlos lo más pequeños posible. El artículo incluye dos plantillas de ejemplo y recalca que el hábito clave es la auto-revisión antes de pedir el tiempo de un compañero.