En pocas palabras: Tetsuaki Hamano abrió el PR #22211 en Gutenberg en mayo de 2020: un cambio de una sola línea. Seis años después sigue mergeado y él se volvió contribuidor habitual del proyecto. En WordPress, que mueve el 40% de la web, cualquier aporte chico cuenta.
En mayo de 2020, un desarrollador japonés llamado Tetsuaki Hamano mandó su primer pull request a Gutenberg: un cambio de una sola línea de código. Seis años después, ese PR (el #22211 en el repo de WordPress/Gutenberg) sigue mergeado en el editor de bloques que usás todos los días, y él terminó siendo un contribuidor recurrente del proyecto. Las contribuciones pequeñas tienen ese impacto en WordPress: una línea puede abrirte la puerta a todo el ecosistema.
Contribuir a WordPress es el proceso de aportar código, traducciones, documentación, testing o soporte al software libre que mueve más del 40% de la web, coordinado a través de repositorios en GitHub, foros oficiales y equipos (Make Teams). No hace falta ser programador senior ni tener commits históricos: un fix de CSS de una línea, como el de Hamano, cuenta igual que una feature grande. El proyecto se sostiene con miles de aportes chicos.
En 30 segundos
- Tetsuaki Hamano abrió el PR #22211 en Gutenberg en mayo de 2020, su primer aporte, un cambio de una sola línea.
- Seis años después (según su propio posteo de agosto de 2026) sigue involucrado con WordPress y lo cuenta como algo que «cambió su vida».
- Para tu primer PR alcanza con forkear el repo, crear una branch, hacer el cambio, pasar los tests y abrirlo con una descripción clara.
- No todo es código: traducción, documentación, soporte en foros, testing y diseño son contribuciones igual de válidas.
- La comunidad tiene Contributor Days, Slack y handbooks para que no arranques solo.
¿Quién es Tetsuaki Hamano y cómo llegó a WordPress?
Tetsuaki Hamano es un desarrollador japonés que empezó a contribuir a WordPress en 2020 con un pull request mínimo en el repositorio de Gutenberg. En un posteo que rebotó Matt Mullenweg (@photomatt) en agosto de 2026, contó que cuando mandó ese PR de una sola línea no se imaginaba que iba a terminar tan metido en el proyecto. «La vida es curiosa», escribió.
No es un caso raro. Mucha gente entra al open source por una molestia puntual: encontrás un bug chiquito, te da bronca, y en vez de esperar que otro lo arregle, lo arreglás vos. Ese es el gancho. Y una vez que viste tu nombre en el changelog, es difícil volver atrás. Ya lo cubrimos antes en la comunidad de WordPress detrás de cada versión.
¿Qué era el PR #22211 y por qué importa?
El PR #22211 fue el primer aporte de Hamano al editor de bloques: un cambio acotado, de una línea, sobre el comportamiento de un bloque en Gutenberg, abierto y mergeado en el ciclo de mayo de 2020. Suena a poco. Y en volumen de código, lo es. Pero acá está el punto: en un proyecto donde miles de personas tocan el mismo repo, que un cambio de una línea pase la revisión, los tests automáticos y termine en producción no es trivial.
Gutenberg es el editor de bloques de WordPress, el proyecto en JavaScript (React) que reemplazó al viejo editor clásico y que hoy también maneja el Full Site Editing. Cada release junta cientos de PRs de gente de todo el mundo. Que el tuyo entre significa que tu criterio pasó el filtro de los mantenedores. Eso, para un primer aporte, es un golazo.
¿Por qué las contribuciones pequeñas son el corazón de WordPress?
Porque el software libre no se construye con héroes solitarios que escriben features gigantes, sino con muchísima gente haciendo cambios chicos y sostenidos. WordPress es libre y abierto, y cualquiera puede leer, modificar y proponer mejoras al código, según explica la documentación oficial de WordPress. Ese modelo distribuido es lo que lo mantiene vivo hace más de veinte años.
Pensalo así. Un fix de CSS. Una traducción de tres strings. Un typo corregido en el handbook. Un bug reportado con pasos claros para reproducirlo. Ninguna de esas cosas sale en un titular, pero sumadas son literalmente el proyecto. La «innovación» en WordPress no es un evento, es un goteo constante.
Y hay algo que Hamano capta bien: los cambios chicos te enseñan el proyecto por dentro. Cuando arreglás una línea, tenés que entender el bloque, el sistema de tests, el flujo de review, las convenciones. Terminás sabiendo más de Gutenberg que si hubieras leído la documentación entera de corrido. Para más detalles técnicos, mirá crear tu primer proyecto en WordPress.
¿Cómo hago mi primer pull request en Gutenberg?
Para tu primer PR en Gutenberg necesitás una cuenta de GitHub, Node.js instalado y seguir el flujo Git estándar que documenta el handbook del block editor. El proceso es siempre el mismo, sea un fix de una línea o algo más grande.
- Forkeá y cloná el repo: hacé un fork de WordPress/gutenberg a tu cuenta y clonalo en tu máquina.
- Creá una branch descriptiva: el handbook recomienda el patrón
[tipo]/[descripción], por ejemplofix/button-margin. Nunca trabajes sobre trunk. - Hacé el cambio y corré los tests: Gutenberg tiene su suite de tests; si tu cambio los rompe, arreglalo antes de seguir.
- Commiteá con un mensaje claro: que se entienda qué cambiaste y por qué, sin necesidad de abrir el diff.
- Abrí el PR con contexto: explicá el problema, cómo lo resolviste y cómo probarlo. Un buen PR le ahorra media hora al revisor.
¿Tiene que ser un cambio grande para que valga? No. El de Hamano fue una línea. Los fixes de CSS, los ajustes de documentación y los typos son bienvenidos, y de hecho son la mejor puerta de entrada porque el riesgo de romper algo es bajo.
¿Qué tipos de contribuciones necesita WordPress si no programo?
WordPress necesita mucho más que código: traducciones, documentación, soporte en los foros, testing, diseño, accesibilidad y reportes de bugs son contribuciones oficiales, cada una con su propio equipo (Make Team). Si no escribís JavaScript ni PHP, igual tenés lugar. Los equipos están listados en el handbook de la comunidad.
Traducción (Polyglots)
Si hablás español y otro idioma, podés traducir el core, plugins y themes. Es de las formas más directas de tener impacto: una cadena bien traducida la ven millones de usuarios.
Soporte y documentación
Responder en los foros de soporte o mejorar el handbook no requiere tocar una línea de código. Y si alguna vez te salvó una respuesta en el foro, sabés lo que vale que alguien se tome el trabajo de contestar. Tema relacionado: probar cambios en un ambiente seguro.
Testing y reporte de bugs
Probar las versiones beta y reportar qué se rompe, con pasos claros para reproducirlo, es oro para los desarrolladores. Un buen reporte de bug a veces ahorra más tiempo que el propio fix.
Un detalle que ayuda mucho: los Contributor Days, que se hacen en los WordCamps, tienen mentores que te acompañan en tu primer aporte. No arrancás mirando un repo gigante sin saber por dónde empezar; hay alguien al lado explicándote el flujo.
¿Cómo conecto con la comunidad WordPress y crezco como contributor?
La comunidad WordPress se organiza en el Slack oficial (make.wordpress.org), los Make Teams por área, los WordCamps presenciales y grupos regionales en español. Es el soporte que sostiene a los contribuidores nuevos desde el primer PR, y guías como la de Nelio Software desglosan el flujo técnico paso a paso.
Eso sí: hay un tema del que se habla poco. Mantener el equilibrio como contribuidor de open source es difícil. La guía de Open Source Guides lo dice sin vueltas: el burnout de los mantenedores es real, y por eso las contribuciones chicas y bien hechas descargan trabajo del que ya está adentro. Entrás ayudando, no pidiendo.
Errores comunes al empezar a contribuir
- Arrancar con algo enorme: mucha gente quiere que su primer PR sea una feature completa y se frustra en la review. Empezá chico, como Hamano. Una línea también entra.
- No leer las guías del proyecto: WordPress y Gutenberg tienen convenciones de branch, commit y estilo. Si las ignorás, tu PR se traba en detalles que no tienen que ver con el código.
- Abrir el PR sin tests o sin descripción: un revisor que no entiende qué hiciste ni cómo probarlo lo va a dejar para después. Un PR autoexplicativo se mergea más rápido.
- Tomárselo a lo personal: que te pidan cambios en la review no es un rechazo, es cómo funciona el proceso. Todos los PRs pasan por ahí, incluso los de los core committers.
Preguntas Frecuentes
¿Puedo contribuir a WordPress si soy principiante?
Sí. WordPress recibe aportes de principiantes en código, traducción, documentación, soporte y testing. El caso de Tetsuaki Hamano lo muestra: su primer PR en Gutenberg fue un cambio de una sola línea, y hoy es un contribuidor recurrente. Empezá con un fix chico y el proceso te va guiando. Relacionado: mantener tu sitio en perfecto estado.
¿Qué impacto tiene una contribución pequeña?
Un cambio de una línea puede quedar en producción y afectar a millones de sitios, porque WordPress mueve más del 40% de la web. El PR #22211 de Gutenberg sigue mergeado seis años después. En un proyecto colaborativo, la suma de aportes chicos es literalmente el software.
¿Necesito saber programar para contribuir?
No. WordPress tiene equipos oficiales de traducción (Polyglots), documentación, soporte, diseño, accesibilidad y testing. Si no escribís código, podés traducir cadenas, responder en los foros o reportar bugs con pasos claros para reproducirlos, y todo eso cuenta como contribución.
¿Dónde pido ayuda para mi primer aporte?
En los Contributor Days de los WordCamps, donde hay mentores que te acompañan, y en el Slack oficial de make.wordpress.org. El handbook de la comunidad lista los equipos por área. No hace falta que arranques solo mirando un repo gigante.
¿Cómo abro un pull request en el repo de Gutenberg?
Forkeás WordPress/gutenberg en GitHub, lo clonás, creás una branch con el patrón [tipo]/[descripción], hacés el cambio, corrés los tests, commiteás con un mensaje claro y abrís el PR explicando el problema y cómo probarlo. El flujo completo está en el handbook del block editor.
Conclusión
La historia de Hamano no es sobre una línea de código. Es sobre lo que pasa después de esa línea: seis años de involucramiento que empezaron con un fix mínimo y el envión de ver que tu aporte entra al proyecto. Si venís usando WordPress hace tiempo y nunca contribuiste, el paso más difícil es el primero, y justamente por eso conviene que sea el más chico posible.
Elegí un bug que te moleste. Leé el handbook, forkeá el repo, mandá el PR. Si no programás, traducí tres cadenas o respondé en el foro. Y si vas a montar un WordPress local para probar cambios antes de subirlos, después podés llevarlo a un hosting WordPress como el de Donweb sin dramas. Lo importante es dar el primer paso: en WordPress, las cosas grandes empiezan siempre con algo chico.
