La guía abierta para

Un manual comunitario sobre cómo los equipos reales entregan software.

Leer el manual
~/atlas · git
mainfish
$
Licencia
MIT
libre y abierto, para siempre
Compatibilidad
Cualquier stack
independiente del lenguaje
Guías activas
13+
nuevas cada semana
Colaboradores
Open
sé el #2 · únete pronto →
Lo que encontrarás

Respuestas prácticas, no opiniones disfrazadas de buenas prácticas.

Cada guía nace de una base de código real, validada por los maintainers que la enviaron, y se revisa cuando la realidad la contradice. Explora por tema.

Git y flujos de trabajo

Trunk-based, release branches, GitFlow - cuándo cada una vale la pena y las señales de que se te quedó pequeña.

1 guíasactualizado hoy

Pull requests y revisión

Plantillas que sí se revisan, límites de tamaño que se respetan y cómo dejar un comentario que no ponga a nadie a la defensiva.

1 guíasactualizado hoy

Pruebas

Contract tests, higiene de snapshots, matar CI inestable - patrones que aguantan con 50 ingenieros y con 50.000.

1 guíasactualizado hoy

Releases y versionado

Semver en la práctica, changelogs que tus usuarios sí leen y simulacros de rollback que no necesitan un héroe.

1 guíasactualizado hoy

Contribuir al código abierto

Onboarding de nuevos contribuidores, RFCs que se entregan, gobernanza que escala sin ahogar el ritmo.

1 guíasactualizado hoy

Buenas prácticas

Post-mortems, rediseños y las historias de "deberíamos haber hecho esto 6 meses antes" que vale la pena leer.

1 historiasactualizado hoy
Elección de la semana

Guías reales, se leen como si emparejaras con alguien sénior.

guía · 8 min de lectura

Post-mortems sin culpables

Post-mortem sin culpables: cinco porqués más allá del error humano, acciones estructurales frente a pulido y patrón de difusión que construye memoria institucional.

DGDayron Glez
rfc
actualizado hoy
Leer la guía

#El modelo mental: los incidentes revelan el sistema, no al operador

Un proveedor de pagos devuelve errores 500 durante cuarenta minutos. El equipo escribe un post-mortem. La acción resultante es "mejorar la monitorización del proveedor de pagos." Seis meses después, un proveedor diferente devuelve errores 500 durante una hora. El nuevo post-mortem dice "mejorar la monitorización de ese proveedor también." Los post-mortems son inculpadores, puntuales y bien asistidos. También son inútiles. Siguen documentando…

Por qué openbranch

Construido como las bases de código que documenta.

de la comunidad

Cada guía es un PR.

Sin guardianes. El mismo flujo que documentamos es el que usamos para escribir la documentación.

agnóstico al stack

Sin agenda de framework.

Si un patrón solo funciona en un stack, lo decimos. La mayoría aquí son más viejos que tu build tool.

versionado

Consejos con caducidad.

Cada guía está fechada, versionada y se revisa. Retiramos a propósito los patrones que no envejecieron bien.

hecho por la comunidad

El manual mejora cada vez que abres un PR.

¿Encontraste un patrón que funcionó? ¿No estás de acuerdo con una guía? Abre un pull request, cuenta tu historia o solo añade una frase - así como trabajamos es como crece la documentación.

Abre tu primer PRExplora el repo