Pull Request en inglés: cómo escribirlo sin frenar tu review

Subes el Pull Request en inglés a las 18:42, cierras el laptop, te vas. A las 09:15 del día siguiente alguien al otro lado del océano lo abre. Si tu descripción es clara, te lo aprueban antes del primer café; si no, te toca despertarte con tres comentarios pidiendo contexto y un día más perdido en el ciclo de review.

Escribir una descripción que un revisor pueda procesar en dos minutos no va de gramática perfecta — va de estructura, vocabulario concreto y honestidad sobre lo que has tocado. Aquí están las frases reales que uso a diario, los fallos que veo una y otra vez en PRs de compañeros, y un par de plantillas que puedes copiar tal cual.

<Callout type="info">
**¿Cómo se escribe un Pull Request en inglés que el revisor apruebe rápido?**

Estructura el Pull Request en inglés con tres bloques: What (qué cambia), Why (por qué) y How to test (cómo probarlo). Empieza con verbos en imperativo o tercera persona ("Adds validation...", no "I have added..."), justifica el cambio en una o dos frases y cierra con pasos numerados de prueba.
</Callout>

## La estructura mínima de un Pull Request en inglés que sobrevive a cualquier review

Un PR description útil en inglés tiene siempre tres bloques: **What**, **Why** y **How to test**. No tres frases bonitas, tres bloques claros. El revisor escanea, no lee. Si en diez segundos no entiende qué tocaste, por qué lo tocaste y cómo verificar que no rompiste nada, salta al siguiente PR y vuelve mañana — o pasado.

Esta es la plantilla que tengo guardada como snippet en el IDE:

```md
## What
Brief description of the change in 1-2 lines.

## Why
Context: the bug, the ticket, the user-facing problem.
Link to JIRA/Linear/issue.

## How to test
1. Step one
2. Step two
3. Expected: …

Tres bloques, sin adornos. Cuanto más senior es el equipo, más agradecen esto. Lo he visto en proyectos enterprise donde el coste de un mal merge se mide en incidencias de producción: este esqueleto no es preferencia personal del lead, es disciplina del equipo.

Cómo describir el "what" sin sonar a traducción de Google

El "what" es la frase que más se cuela mal. La gente traduce literal del español y suena rarísimo. "I have made the change" no es incorrecto, pero ningún nativo lo escribe en un PR. Usa el simple past o, mejor, el presente en tercera persona:

Fíjate en un detalle clave: el sujeto desaparece. En títulos de commit y descripciones de PR, la convención inglesa es modo imperativo o tercera persona breve. "Add validation…", "Fix race condition in…", "Refactor user service to…". Arrancar con "I added…" no es un error gramatical, pero te delata como no-nativo y, lo que es peor, ocupa espacio sin aportar información. Tu reviewer ya sabe que el PR es tuyo, lo dice el avatar arriba.

Otro patrón que ayuda: verbos concretos. No escribas "I changed the file". Escribe "Replaced the manual JWT parsing with the spring-security helper" o "Extracted the retry loop into a separate strategy class". El verbo cuenta la historia. Si te sale "changed", "updated" o "modified" como verbo principal, casi seguro puedes hilar más fino.

El "why" es lo que se salta el 90% (y por eso te frenan)

El "what" lo escribe casi todo el mundo. El "why" no. Y es justo la parte que el reviewer necesita para aprobar sin pelearse contigo en los comentarios. Si no le cuentas el motivo del cambio, va a asumir lo peor: que estás metiendo algo gratis, que no entendiste el ticket, o que introduces deuda técnica sin razón.

Tres plantillas que funcionan en la inmensa mayoría de casos:

• "This addresses the regression reported in TICKET-123 where users with two-factor enabled couldn't log in after a password reset."
• "We were paying the cost of building this DTO on every request even when not needed. This caches it for the lifetime of the session."
• "Following up on the discussion in PR #482 — splitting the helper out so we can reuse it from the worker service."

Pienso que esta es la mayor diferencia entre un dev junior y uno con kilómetros: el junior cuenta lo que hizo, el sénior cuenta por qué. Tu reviewer también lo piensa, aunque no te lo diga.

Frases para pedir review, responder a comentarios y cerrar hilos

Aquí va el inglés operativo del día a día. Las expresiones que repites tres veces por sprint y que conviene tener interiorizadas — y que puedes practicar en voz alta con un tutor hasta que te salgan sin pensar.

Para pedir review en Slack o GitHub:

• "Ready for review whenever you have a moment."
• "Could you take a look when you get a chance? No rush."
• "This one's blocking the deploy — quick look when you can?" (sólo cuando de verdad urge)

Para contestar a un comentario donde el reviewer te pilla en algo:

• "Good catch — fixed in the latest commit."
• "You're right, that doesn't handle the null case. Updated."
• "Fair point. I went back and forth on this; let me push a follow-up commit."

Para defender una decisión sin entrar al trapo (que es justo donde el inglés de un PR se cruza con hacer un code review sin sonar brusco):

• "I considered that approach, but it would break X. Happy to discuss if you see a way around it."
• "That's a fair concern. I'd argue the tradeoff is worth it because the alternative duplicates the parsing logic in three places."

Para cerrar un hilo:

• "Resolving — addressed in the latest commit."
• "Resolving as won't-fix for now; tracked in TICKET-123."

Pequeño truco que vale oro: "good catch" es la respuesta universal cuando alguien te encuentra un fallo. Es educada, reconoce el mérito y cierra el bucle. Úsala sin miedo — los reviewers la sueltan también contigo y nadie se siente menos por ello.

Errores de inglés que más frenan un review

Estos los veo cada semana en PRs de compañeros. No son fallos gramaticales graves, son roces que ralentizan al revisor y, en el peor caso, le hacen entender otra cosa de lo que querías decir:

1. "Actual" no significa "current". "The actual implementation" significa "la implementación real, no la que tú crees". Para la implementación de ahora se dice "the current implementation". Es el falso amigo número uno en PRs hispanohablantes.
2. "Eventually" no significa "eventualmente". Significa "al final, tras un tiempo". "Eventually consistent" no es "consistente por casualidad", es "consistente al cabo de un rato".
3. "Assist to a meeting" no existe. Es "attend a meeting". Acudir a una reunión es "attend"; "assist" en inglés es ayudar, no presentarse.
4. "Make" cuando querías "get" o "build". "I make the tests pass" suena raro. Es "I got the tests to pass" o, en past simple, "Made the tests pass" funciona, pero "I make…" no.
5. "Than" vs "that". "Better than the previous one", no "better that the previous one". Es typo, pero el revisor tiene que parar a descifrarlo.

Cómo avisar de breaking changes, migraciones y riesgo en inglés

Hay un bloque que las plantillas serias incluyen y casi nadie redacta bien: el aviso de riesgo. Si tu PR rompe compatibilidad, necesita una migración, o exige tocar config antes de desplegar, decirlo claro en inglés es lo que separa un merge limpio de un incidente a las tres de la tarde. El revisor no quiere descubrir el ALTER TABLE cuando ya está en producción.

Las frases que uso para marcar esto, sin dramatizar y sin esconderlo:

• Breaking change: "Heads up: this is a breaking change. Clients calling /v1/users will need to update to the new response shape before this is deployed."
• Migración de base de datos: "This PR includes a DB migration (V42__add_status_column.sql). Run it before deploying the app, not after."
• Cambio de config: "Requires a new env var RETRY_MAX_ATTEMPTS set before deploy. I've added it to the staging config already; prod is still pending."
• Orden de despliegue / PR dependiente: "Depends on #501 — merge that one first, otherwise the worker won't pick up the new queue name."
• Riesgo acotado: "Low risk: the change is behind the new-checkout feature flag, off by default in prod."

Dos expresiones que conviene tener fichadas. "Heads up" es el "aviso" informal y estándar para señalar algo importante sin sonar alarmista — abre la frase con eso y el reviewer ya sabe que viene un detalle que no puede saltarse. Y "backwards-incompatible" (o "breaking change") es el término exacto: no escribas "this change is not compatible", que suena vago. Si además puedes contar cómo lo mitigas — un feature flag, un despliegue en dos fases, un fallback — dilo en la misma línea. Eso es lo que hace que un sénior apruebe en lugar de pedirte una llamada.

Cuándo NO aplica

No todo PR necesita la estructura completa de tres bloques. Si estás bumpeando una dependencia de patch (de 1.2.3 a 1.2.4), una sola línea sobra: "Bumps axios to 1.2.4 to pick up the security fix in CVE-2024-XXXX". Punto. Aplicar la plantilla de tres bloques a esto es ruido.

Tampoco aplica si tu equipo trabaja en español y los PRs los escribís en español por acuerdo común. No hay regla universal — la regla es la convención de tu equipo. Si tu empresa está distribuida pero todo el dev team es hispanohablante, escribir PRs en inglés "porque queda más profesional" es ceremonia inútil. Optimiza para quien lee.

Y la última excepción: hotfixes a las dos de la mañana. Cuando hay producción caída, el mensaje del PR es "Hotfix: null check in OrderService::save. Will write proper post-mortem tomorrow." Y se mergea. La descripción larga viene después, en el RCA — igual que contar ese mismo bug en la daily del día siguiente es otra conversación distinta, con sus propias frases.

Chuleta rápida

Las expresiones más reutilizables, todas juntas para tenerlas a mano. Si quieres llevarlas más allá del PR, las tengo ampliadas en 100 palabras de vocabulario técnico que oyes de verdad, y para que se fijen de verdad ayuda repasarlas con flashcards de repaso espaciado.

Preguntas frecuentes

¿Tengo que escribir también el título del PR en inglés si el equipo es bilingüe?

Si el repo lo va a leer alguien que no habla español — un contributor externo, un security audit, tu jefe dentro de seis meses cuando se haya olvidado del contexto — sí. El historial de Git es para siempre. El coste de escribirlo en inglés son cinco segundos extra; el coste de tenerlo en español y que alguien tenga que traducirlo dentro de tres años es real.

¿Está mal pedirle el PR description a una IA?

Para nada — yo lo hago. Lo que sí está mal es copiarlo sin revisar. La IA te da un buen punto de partida, pero el "why" lo conoces tú, no ella. Apóyate en ella para pulir gramática y vocabulario; el contenido lo aportas tú. Es justo el tipo de trabajo donde un dev que usa la IA con criterio va a sacar siempre mejor PR description que uno que no la toca, o que uno que la deja a piloto automático.

¿Y si mi inglés es realmente flojo y aun así tengo que escribir el PR?

Empieza con la plantilla literal: tres bloques con frases simples. No intentes sonar elegante. "Adds X. Fixes the bug where Y. Tested by Z." sirve perfectamente. La elegancia llega con los meses. Lo importante es que el reviewer entienda. Y cada Pull Request en inglés que escribes es una rep más — al cabo de seis meses de hacerlo a diario, la diferencia es bestial. Sin curso, sin academia, sólo constancia. Y si quieres seguir afinando cómo te comunicas en un PR o en los comentarios, tengo más posts sobre code review en esa misma línea.

<ProductCTA variant="prominent">
¿Quieres practicar esto con un tutor IA? Empieza gratis en DevLingo.
</ProductCTA>