Michael JohnsonDesde el 11 de noviembre de 2026, los propietarios de cuentas personales de GitHub pueden configurar tipos y campos de tarea en los repositorios que les pertenecen. Las herramientas de planificación anunciadas anteriormente ya están disponibles para desarrolladores individuales y responsables de proyectos de código abierto. GitHub también permite gestionar tipos y campos mediante las API REST y GraphQL, así como con webhooks, según anunció la empresa.
Qué llega a los repositorios personales
El titular de la cuenta puede configurar hasta 25 tipos de tarea. De forma predeterminada están disponibles Bug, Task y Feature; es posible modificarlos o añadir otros. También se pueden crear hasta 25 campos para las tareas, como prioridad, esfuerzo, fecha de inicio y fecha objetivo. Se admiten campos de texto, numéricos y de calendario, además de opciones de selección única y múltiple.
Los campos pueden asignarse a tipos de tarea concretos o ponerse a disposición de las tareas sin tipo. Se pueden indicar al crear una tarea y editar después en una tarea existente. En GitHub Projects, los campos sirven para crear vistas personalizadas y modificar valores en bloque.
Qué utilidad tiene para quienes mantienen proyectos
En un proyecto pequeño, los tipos de tarea y los campos ofrecen una forma común de describir el trabajo. Por ejemplo, quienes lo mantienen pueden distinguir entre errores, funciones y tareas generales, e indicar la prioridad o la fecha objetivo de cada una. En los proyectos, estos datos ayudan a filtrar y agrupar tareas sin sacar la planificación de GitHub Issues.
El cambio amplía el acceso a la planificación estructurada para desarrolladores individuales y responsables de repositorios pertenecientes a cuentas personales. Los tipos y campos se configuran en los ajustes de esa cuenta; el anuncio de GitHub no promete que la configuración se sincronice automáticamente entre distintas cuentas o repositorios.
Qué se puede automatizar
GitHub señala que los tipos y campos se pueden gestionar mediante programación a través de las API REST y GraphQL y de los webhooks. La documentación describe operaciones con campos, sus valores y los cambios notificados por el evento issues. Esto permite a los desarrolladores integrar sus propios flujos de trabajo: por ejemplo, reaccionar cuando cambia el valor de un campo o establecerlo mediante programación. Cada integración debe implementarse por separado.
En la misma actualización, GitHub añadió la posibilidad de crear etiquetas y milestones directamente desde una tarea cuando no aparece en la lista el valor adecuado. Esta pequeña mejora simplifica el trabajo con las tareas; el cambio principal es que los tipos y campos configurables ya están disponibles en los repositorios de cuentas personales.
Para un proyecto individual, el resultado son Issues más estructuradas y la posibilidad de gestionar campos mediante API y webhooks. La utilidad dependerá de las categorías y los datos que cada responsable elija para sus tareas.
