GitHub makes issue fields generally available for structured project tracking

GitHub has made issue fields generally available, moving a planning feature for structured issue metadata out of preview and into every organization on Free, Team, Enterprise, and GitHub Enterprise Cloud with data residency plans. The company says the feature will also ship with GitHub Enterprise Server 3.23.

Issue fields let teams attach typed values to issues, such as priority, effort, start date, target date, or organization-specific custom fields. That matters for software teams that use issues as more than a bug tracker: the same issue can now carry consistent metadata for triage, planning, reporting, and cross-repository work without every repository inventing its own label conventions.

What changed

According to GitHub, more than 40,000 organizations adopted issue fields during the public preview that began in May. The general availability release adds field values directly to repository issue lists, so teams can scan priority or effort without opening each item. Public projects are now supported as well, with visibility controls that let organizations decide which fields nonmembers can see. Logged-out visitors can view fields that an organization marks as public.

The release also adds access through GitHub's MCP server, allowing AI tools such as Copilot to read and set issue field values when creating or updating issues. That connection is notable because it turns structured planning data into something automation can use, instead of leaving status and priority buried in prose comments or loosely managed labels.

• Default fields include Priority, Effort, Start date, and Target date.
• Admins can customize fields and decide which fields appear on each issue type.
• Field names now support non-English characters.
• GitHub says the release includes fixes for timestamp updates, project sorting, autocomplete, and single-select option ordering.

The same changelog post also notes a storage change for edit history: GitHub now limits issue, issue comment, pull request, and pull request review comment edit histories to 100 stored entries. When a new edit exceeds that limit, the oldest intermediate edit is removed while preserving the original content and the most recent 99 edits. GitHub says the limit reflects typical API usage, where more than 97% of API consumers do not paginate beyond the first page.

For organizations already standardizing work intake in GitHub Projects, issue fields should reduce the need for duplicated labels and manual project-only metadata. For enterprises, the combination of repository issue-list visibility, public-project controls, and upcoming Enterprise Server support makes the feature easier to roll out across mixed cloud and self-hosted planning environments.

Sources

• github.blog

Cover photo by cottonbro studio on Pexels, used under the Pexels License.