Empieza por los errores caros
Un linter puede revisar miles de frases en segundos, así que es tentador codificar cada preferencia editorial. No lo hagas. Empieza por nombres de producto incorrectos, terminología inconsistente, lenguaje de riesgo, warnings ambiguos y errores repetitivos de formato.
Si la primera ejecución genera cientos de avisos de poco valor, el equipo aprenderá a ignorar la herramienta.
Trata las reglas como código
Guarda la configuración de Vale y los vocabularios en el repositorio. Revisa sus cambios y usa nombres que expresen intención. ApprovedProductNames se entiende mejor que RegexRule17.
Mantén ejemplos pequeños que deban pasar y fallar para evitar regresiones en las reglas.
Separa errores y recomendaciones
Bloquea el build solo por problemas que el equipo haya acordado que deben corregirse. Usa warnings para patrones que requieren juicio editorial. Así el CI sigue siendo predecible.
Cuida el vocabulario
La terminología suele ofrecer el retorno más rápido. Mantén nombres aprobados, mayúsculas y reemplazos de forma central. Añade excepciones de producto de forma explícita en lugar de desactivar reglas completas.
Los falsos positivos también aportan información: a veces la regla está mal; otras veces el modelo de contenido dificulta la consistencia.
La edición humana sigue siendo humana
Vale no sabe si una explicación responde a la pregunta correcta ni si el ejemplo enseña el modelo adecuado. Automatiza defectos repetibles y reserva la atención editorial para estructura, evidencia y claridad.
Un buen quality gate casi resulta aburrido: detecta siempre los mismos problemas importantes y rara vez sorprende al autor.
Ejemplo aplicado
Trata «Usa Vale como quality gate, no como policía de puntuación» como una evaluación pequeña, no como una comparación de listas de funciones. Elige tres muestras reales: una página sencilla, otra con código o datos estructurados y una tercera con navegación, reutilización o localización. Pruébalas con la herramienta o método y anota qué se simplifica y qué nuevo coste de mantenimiento aparece.
Evalúa el trabajo que el equipo repetirá cada semana:
- si la fuente es comprensible para el autor;
- si el revisor puede ver un diff significativo;
- si un fallo de build señala un problema corregible;
- si el contenido puede moverse, localizarse o reutilizarse sin limpieza manual.
Una buena herramienta reduce incertidumbre en autoría, revisión y publicación. Si la complejidad se desplaza a configuración frágil, plugins o a la memoria de una sola persona, ese coste también cuenta.
Lista rápida de revisión editorial
- Empieza por los errores caros. Un linter puede revisar miles de frases en segundos, así que es tentador codificar cada preferencia editorial.
- Trata las reglas como código. Guarda la configuración de Vale y los vocabularios en el repositorio.
- Separa errores y recomendaciones. Bloquea el build solo por problemas que el equipo haya acordado que deben corregirse.
- Cuida el vocabulario. La terminología suele ofrecer el retorno más rápido.
