GitHub tipos de issues y campos de issues: 25 y 25

GitHub tipos de issues y campos de issues ya están disponibles en los repositorios de cuentas personales, con un tope claro: cada cuenta puede crear hasta 25 tipos y hasta 25 campos propios. GitHub publicó el cambio el 11 de noviembre de 2026 en su registro oficial de novedades y lo dejó en disponibilidad general, sin lista de espera y sin cambiar de plan. Quien mantiene un proyecto solo, con las etiquetas como único orden, recibe la misma estructura de planificación que las organizaciones usan desde 2025.

El problema que ataca es concreto. En un repositorio personal, la prioridad vivía dentro del nombre de una etiqueta, la fecha de entrega quedaba en una frase del cuerpo y el esfuerzo se guardaba en la memoria de quien mantiene el código. Eso funciona con cinco pendientes. Con cuarenta, la lista se vuelve un muro de títulos parecidos donde nada dice qué va primero, y cada revisión empieza abriendo issue por issue para reconstruir el panorama.

Los tipos responden una pregunta simple: qué clase de trabajo es cada pendiente. De serie vienen tres, Bug, Task y Feature, para separar el error que hay que corregir, la tarea de mantenimiento y la función nueva que alguien pidió. Cada tipo lleva nombre, descripción y color, y sirve para filtrar con consultas del tipo type:Bug. GitHub Changelog detalla que los tipos se definen una sola vez en los ajustes de la cuenta, en la página Issue types del apartado Planning, y valen para todos sus repositorios. Desactivar un tipo no borra nada; borrarlo sí es definitivo.

Campos con datos, no etiquetas con parches

Los campos aportan la otra mitad: dónde está parado cada pendiente y cuánto cuesta moverlo. De serie se crean cuatro, Priority, Effort, Start date y Target date, con Priority ordenada en Urgent, High, Medium y Low y Effort en High, Medium y Low dentro de la documentación oficial de GitHub. Un campo puede ser de texto, número, fecha, selección única o selección múltiple, y admite hasta 100 opciones cuando es de selección única. La fecha deja de ser una frase amable dentro del cuerpo y pasa a ser un dato que se puede ordenar, filtrar y comparar.

GitHub Docs explica que cada campo se puede fijar a tipos concretos o quedar para issues sin tipo: Severity solo en los Bug, Impact solo en los Feature, y Priority en todo. Los fijados aparecen en la barra lateral del issue, con un máximo de 10 por tipo, y cada cambio queda registrado en la línea de tiempo. La visibilidad se decide campo por campo: Restricted, la predefinida, solo lo muestra al dueño y a los colaboradores; Public lo muestra a cualquiera, útil en código abierto.

Donde el cambio se nota de verdad es en Projects. Tipos y campos funcionan como columnas de la vista: se agrupa, se ordena y se filtra por ellos, se arman gráficos y se editan valores en bloque para un grupo de issues a la vez. La búsqueda acepta sintaxis de campo, con consultas como field.priority:high para reunir todo lo urgente o una fecha objetivo a partir de un día concreto. Preguntar qué features de prioridad alta siguen abiertos esta semana dejaba de exigir una lectura completa de la lista: una consulta lo resuelve.

Automatización por API y dos límites claros

La gestión completa se puede programar. GitHub Changelog confirma que las API REST y GraphQL y los webhooks permiten crear tipos y campos, fijar valores en un issue y limpiarlos, con eventos que avisan cada cambio de valor. Eso abre la puerta a reglas con GitHub Actions, como dejar un aviso cuando una fecha objetivo queda vencida. Nada viene armado de fábrica: cada quien escribe su regla. El anuncio suma un arreglo menor: crear etiquetas e hitos desde el propio issue cuando la búsqueda no encuentra coincidencia.

Conviene tener claros los dos límites que marca la documentación. Primero, los campos viven solo en los issues: las pull requests no admiten campos de issue, así que nadie puede ponerle Priority a una pull request ni filtrar esa lista por campos. Segundo, los valores no se pueden rellenar de antemano con parámetros en la dirección ni fijarse desde las plantillas de issues; se ponen en la barra lateral, en Projects, por API o con Actions. Quien esperaba repartir un enlace con los campos ya llenos tendrá que esperar otra vuelta.

Las organizaciones recibieron los tipos en abril de 2025 y los campos meses después; GitHub extendió el paquete cuando ya estaba probado en equipos grandes. El movimiento encaja con una plataforma que empuja el trabajo con agentes, como ya se vio cuando GitHub llevó su agente de código a Slack y Teams para abrir pull requests desde el chat: cada vez se abren más issues por día, también en repositorios de una sola persona, y ese volumen pide datos ordenados en vez de etiquetas improvisadas.

Para el mantenedor con dos o tres proyectos a la vez, la cuenta es corta: tres tipos de serie, cuatro campos de serie y una vista de Projects ordenada por Target date ya separan lo urgente de lo que puede esperar, sin pagar nada. El tope de 25 y 25 queda lejos para casi todos; el límite real será revisar esa vista cada semana y mover las fechas vencidas, porque un campo que nadie mira se convierte en otra etiqueta más.

Fuente: GitHub Changelog