GitHub Projects ha incorporado búsqueda avanzada en la barra de filtros de sus vistas. La funcionalidad, anunciada por GitHub como disponible de forma general, permite construir expresiones con los operadores lógicos AND y OR para definir vistas más precisas sin tener que mantener tantas variantes casi duplicadas.
La mejora puede parecer menor si se observa solo como una ampliación del cuadro de búsqueda. En la práctica, afecta a una necesidad habitual en equipos de ingeniería: representar preguntas operativas que combinan estado, prioridad, responsable, área funcional o tipo de trabajo. Un proyecto de plataforma, seguridad o producto rara vez se gestiona con una única dimensión. Un issue puede ser relevante porque bloquea una release, porque afecta a seguridad, porque pertenece a una iniciativa crítica o porque requiere revisión de arquitectura.
Hasta ahora, muchos equipos resolvían esa complejidad creando vistas separadas para cada combinación. Con búsqueda avanzada, parte de esa lógica puede expresarse directamente en el filtro de una vista.
Qué cambia en GitHub Projects
La novedad principal es que la barra de filtros de las vistas de GitHub Projects acepta expresiones con AND y OR. Según el anuncio oficial de GitHub, esto permite construir la vista necesaria con lógica booleana, en lugar de mantener una vista distinta para cada pregunta.
La diferencia conceptual es sencilla:
ANDrestringe los resultados: todas las condiciones deben cumplirse.ORamplía los resultados: basta con que se cumpla una de las condiciones.
En un tablero de trabajo, esta diferencia es importante. No es lo mismo buscar elementos que estén en curso y sean de alta prioridad que buscar elementos que estén bloqueados o sean de alta prioridad. La primera consulta reduce el foco; la segunda agrupa escenarios alternativos que requieren atención.
Por ejemplo, en un proyecto con campos adecuados, un equipo podría querer ver únicamente trabajo activo y prioritario. Ese caso encaja con AND. En cambio, una vista de riesgo podría incluir tanto elementos bloqueados como elementos críticos, lo que encaja mejor con OR.
Nota: GitHub ha anunciado el soporte de búsqueda avanzada con
ANDyORen la barra de filtros de GitHub Projects. La sintaxis concreta depende de los campos configurados en cada proyecto y de las capacidades de filtrado disponibles en la interfaz de GitHub Projects. Antes de estandarizar consultas internas, conviene validarlas en el propio proyecto.
Por qué importa para equipos técnicos
GitHub Projects ya permitía organizar trabajo a partir de issues, pull requests y campos del proyecto. El valor de esta mejora está en que las vistas pueden acercarse más a las preguntas reales que se hacen los equipos.
En proyectos cloud, de plataforma o de seguridad suelen convivir varias líneas de trabajo:
- migraciones de infraestructura;
- remediación de vulnerabilidades;
- reducción de deuda técnica;
- automatización de despliegues;
- gobierno de costes;
- soporte a equipos de producto;
- revisiones de arquitectura;
- preparación de releases.
Cuando una herramienta no permite expresar bien esas intersecciones, los equipos suelen compensar con procesos adicionales: etiquetas redundantes, nombres convencionales, vistas duplicadas o revisiones manuales para decidir qué entra en cada reunión.
La búsqueda avanzada ayuda a reducir esa fricción. Una vista deja de ser solo “los elementos con esta etiqueta” y puede convertirse en “los elementos que cumplen esta definición operativa”. Esa diferencia es relevante en revisiones semanales, planificación de sprint, seguimiento de riesgos, comités de arquitectura o reuniones de seguridad.
De vistas duplicadas a vistas intencionales
Una señal clara de que un proyecto necesita filtros más expresivos es la proliferación de vistas muy parecidas:
- bugs críticos;
- bugs críticos de backend;
- seguridad pendiente;
- seguridad pendiente de revisión;
- bloqueos de release;
- trabajo del equipo de plataforma;
- trabajo urgente del equipo de plataforma.
Tener muchas vistas no es necesariamente un problema. El problema aparece cuando muchas de ellas son variaciones de una misma pregunta. Si cada vista codifica manualmente una combinación distinta de filtros, cualquier cambio en la taxonomía del proyecto obliga a revisar varias vistas a la vez.
Con AND y OR, los equipos pueden mantener menos vistas, pero más intencionales. En lugar de crear una vista para cada combinación, pueden diseñar vistas alrededor de preguntas estables:
- ¿Qué bloquea la próxima release?
- ¿Qué requiere revisión de seguridad?
- ¿Qué necesita una decisión de arquitectura?
- ¿Qué trabajo crítico sigue abierto?
- ¿Qué pull requests requieren atención?
El objetivo no es complicar los filtros, sino hacer explícita la lógica que ya se estaba aplicando de forma manual.
Ejemplos conceptuales de uso
Los siguientes ejemplos son orientativos. No deben interpretarse como una guía universal de sintaxis para todos los proyectos, porque los nombres de campos y valores dependen de la configuración concreta de cada GitHub Project.
Un equipo podría usar AND para acotar trabajo que cumpla dos condiciones a la vez:
status:"In progress" AND priority:"High"
La intención sería ver elementos que están en curso y, además, son de prioridad alta. No se trata de listar todo lo que está en curso ni todo lo que es prioritario, sino la intersección de ambas condiciones.
OR, en cambio, permite agrupar alternativas:
area:"Security" OR area:"Identity"
La intención sería revisar elementos que pertenecen al área de seguridad o al área de identidad. Esto evita forzar una etiqueta artificial para agrupar dos dominios relacionados, pero no idénticos.
También puede ser útil combinar filtros para reducir ruido. Por ejemplo, un equipo podría separar una vista estable para trabajo de plataforma y, dentro de ella, aplicar condiciones relacionadas con prioridad, estado o área. La clave es que el filtro exprese una pregunta comprensible para todo el equipo, no solo para quien creó la vista.
Advertencia: Al mezclar operadores lógicos, conviene comprobar los resultados con elementos conocidos. Si aparecen demasiados elementos irrelevantes, o si faltan issues o pull requests que deberían estar incluidos, el filtro no está representando bien la intención operativa.
Nuevo filtro reviews: para pull requests
El mismo anuncio de GitHub incluye otra mejora relevante para equipos que gestionan trabajo mediante pull requests en Projects: un nuevo filtro reviews: para filtrar elementos de tipo pull request por su estado de revisión.
GitHub indica que este filtro se apoya en el campo Reviewers, que registra quién ha recibido una solicitud de revisión y la última revisión enviada por cada persona. Esto puede ser útil para vistas orientadas a code review, por ejemplo:
- pull requests pendientes de revisión;
- cambios bloqueados por falta de aprobación;
- trabajo que necesita atención de reviewers concretos;
- seguimiento de carga de revisión en equipos grandes.
Esta mejora complementa la búsqueda avanzada porque permite que las vistas de Projects reflejen mejor el estado real del flujo de entrega, no solo el estado del issue o del pull request.
Aplicación en flujos de seguridad
La gestión de seguridad no suele funcionar como una cola lineal. Un equipo puede tener hallazgos de auditoría, alertas de dependencias, revisiones de permisos, tareas de cumplimiento y acciones derivadas de incidentes. Algunas requieren mitigación inmediata; otras necesitan análisis; otras dependen de decisiones de arquitectura.
Con filtros más expresivos, GitHub Projects puede representar mejor esa realidad. Una vista de “riesgo activo” podría combinar severidad y estado. Otra vista podría agrupar tareas relacionadas con identidad, autenticación o permisos. Otra podría centrarse en elementos que requieren revisión por parte de seguridad aunque hayan sido creados por equipos de producto.
La búsqueda avanzada no sustituye a una buena taxonomía. Si los campos del proyecto son inconsistentes, los filtros solo harán visible esa inconsistencia. Antes de crear consultas complejas conviene revisar definiciones básicas:
- qué significa que un elemento esté bloqueado;
- cuándo una tarea se considera de alta prioridad;
- qué áreas o dominios existen;
- quién es responsable de mantener los campos actualizados;
- qué vistas se usan como referencia en reuniones o reportes.
Una consulta precisa sobre datos incompletos puede generar una falsa sensación de control. La mejora técnica funciona mejor cuando el equipo ya tiene una semántica compartida.
Aplicación en proyectos de IA y automatización
Los equipos que trabajan con IA generativa, automatización o sistemas agentes suelen mezclar investigación, evaluación, integración, seguridad y operación. Una misma iniciativa puede incluir prompts, evaluaciones, conectores, controles de privacidad, cambios de backend y documentación interna.
En estos casos, una lista plana de tareas puede ocultar dependencias importantes. Los filtros con AND y OR permiten separar mejor estados de madurez o tipos de riesgo. Por ejemplo, un equipo puede necesitar distinguir entre:
- trabajo experimental;
- funcionalidades listas para evaluación;
- cambios pendientes de revisión de seguridad;
- integraciones con servicios externos;
- elementos que no deberían pasar todavía a producción.
La recomendación práctica es no concentrar demasiados significados en una única etiqueta. Es preferible separar dimensiones como capacidad, riesgo, entorno, estado y propietario. Así, las vistas pueden responder preguntas operativas más concretas.
Buenas prácticas para consultas mantenibles
La búsqueda avanzada añade flexibilidad, pero también puede convertirse en deuda si cada vista contiene expresiones largas, opacas y difíciles de revisar. Igual que ocurre con una política de acceso o una regla de automatización, un filtro importante debe poder entenderse meses después.
Algunas prácticas útiles:
-
Nombrar las vistas por su propósito.
“Riesgo de release” comunica mejor la intención que un nombre basado en operadores o valores internos. -
Evitar campos sobrecargados.
Si una etiqueta significa a veces severidad, a veces urgencia y a veces visibilidad ejecutiva, cualquier filtro que la use será ambiguo. -
Validar con ejemplos conocidos.
Antes de dar una vista por buena, conviene comprobar issues o pull requests que deberían aparecer y otros que deberían quedar fuera. -
Documentar convenciones mínimas.
No hace falta una guía extensa, pero sí definir qué campos son obligatorios, qué valores se aceptan y qué vistas son canónicas. -
Revisar las vistas críticas cuando cambie el proceso.
Si una vista se usa para decidir qué entra en una release o qué se reporta a dirección, su filtro forma parte del sistema de trabajo del equipo.
Riesgos y límites
La búsqueda avanzada mejora la expresividad de las vistas, pero no resuelve problemas de calidad de datos. Si los issues no tienen campos asignados, si los responsables no se actualizan o si los estados se usan de forma inconsistente, los resultados serán incompletos.
También existe el riesgo de convertir las vistas en lógica de negocio poco visible. En algunos equipos, los filtros terminan representando decisiones importantes: qué requiere aprobación, qué se considera bloqueante o qué se eleva a dirección. Si esas expresiones viven solo en la interfaz y nadie las revisa, pueden cambiar sin suficiente trazabilidad.
Una mitigación razonable es tratar las vistas críticas como parte del proceso operativo. No necesitan el mismo control que el código de producción, pero sí deberían revisarse cuando cambian los criterios de priorización, release, seguridad o reporting.
Otra novedad del anuncio: retención de estados de despliegue
GitHub también comunicó en el mismo anuncio una nueva política de retención de 90 días para los estados de despliegue. Según GitHub, los estados con más de 90 días se eliminan automáticamente y dejan de aparecer en las APIs REST y GraphQL. El estado actual de un despliegue no se ve afectado.
Este punto no forma parte de la búsqueda avanzada de Projects, pero es relevante para equipos que usan datos históricos de despliegue en integraciones, auditorías internas o automatizaciones. Si alguna herramienta depende de consultar estados antiguos mediante API, conviene revisar el impacto de esta política.
Cómo adoptarlo sin generar ruido
La adopción más efectiva no consiste en rehacer todos los proyectos existentes. Es mejor empezar por una vista donde el equipo ya perciba fricción: una revisión semanal con demasiado ruido, una vista con elementos irrelevantes o varias vistas duplicadas que nadie mantiene.
Un enfoque razonable sería:
- Identificar la pregunta que la vista debería responder.
- Revisar si los campos actuales permiten expresar esa pregunta.
- Crear un filtro simple con
ANDuOR. - Validar los resultados con elementos conocidos.
- Observar la vista durante una o dos iteraciones.
- Ajustarla o descartarla si no mejora la toma de decisiones.
En equipos grandes puede ser útil acordar patrones básicos. Por ejemplo, usar AND para acotar por equipo, iniciativa o estado, y OR para agrupar condiciones alternativas dentro de una misma revisión. Esta convención sencilla ayuda a que las consultas sean más legibles.
Conclusión
La disponibilidad general de búsqueda avanzada en GitHub Projects es una mejora práctica para equipos que gestionan trabajo técnico complejo. El soporte de AND y OR en la barra de filtros permite crear vistas más cercanas a las preguntas reales de ingeniería: qué está bloqueado, qué afecta a seguridad, qué requiere revisión, qué entra en la próxima release o qué pull requests necesitan atención.
El valor no está únicamente en filtrar mejor. Está en reducir vistas duplicadas, hacer explícita la lógica operativa y conectar el seguimiento diario con criterios de riesgo, prioridad y responsabilidad.
La recomendación es empezar con pocas vistas, bien nombradas y apoyadas en campos consistentes. La búsqueda avanzada amplifica la calidad del modelo de trabajo existente; no lo sustituye. Si el proyecto ya tiene una taxonomía clara, AND y OR permiten convertirla en vistas más precisas. Si no la tiene, esta novedad es una buena oportunidad para ordenar primero cómo se describe el trabajo.