Issue fields: Structured issue metadata is in public preview

[ebndev]

issue.fields.public.preview.mp4

If you've ever used labels like priority/p0, severity/high, or team/frontend to track structured data in issues, you know the pain: no types, no validation, no consistency across repositories, and no way to report on them. Issue fields fix all of that. Define typed, org-wide fields once and they show up on every issue, in every repository, automatically. Search by them, report on them, automate with them.

Issue fields are now in public preview. We're rolling out access gradually to select organizations. Not all organizations will have access immediately. If you'd like to be enabled sooner, request access in this discussion (see below).

We've been running a private preview since November 2025 and have been iterating based on feedback. Here's what teams are saying:

"This is fantastic. Probably my top GitHub pain point. I had even drafted a custom app in the past to manage these labels, which I'd be happy to ditch."
— LeaVerou

"We've completely abandoned Atlassian products and moved our whole planning/backlog/iteration work into GitHub, and not having the fields has been a large pain point."
— syntaqx, aspyn-io

"Scoped labels in GitHub!? Is this reality?! 🤯 Scoped labels are the core reason we remained on GitLab."
— alystair, pagedriver

📦 What you get out of the box

When issue fields are enabled for your organization, you get a ready-to-use setup.

Default fields

Every organization starts with four fields:

Field	Type	Values
Priority	Single-select	Urgent, High, Medium, Low
Effort	Single-select	High, Medium, Low
Start date	Date	-
Target date	Date	-

Pinned to the right issue types by default

Field	No type	Bug	Task	Feature
Priority	x	x	x	x
Effort		x	x	x
Start date				x
Target date				x

Create a bug and you'll see Priority and Effort right there in the sidebar. Create a feature and you get all four. No setup, no config, just works.

🔧 Make it your own

The defaults are a starting point. Organization admins can customize everything.

Add new fields

You can add up to 25 fields per organization. Four field types to choose from:

• Single-select - pick from a predefined list (e.g., Severity, Impact, Team)
• Text - free-form text with auto-detected URLs (e.g., DRI, Notes)
• Number - numeric values including decimals (e.g., Story points, Staffing)
• Date - date picker (e.g., Ship date, Review date)

Pin fields to issue types

Decide which fields show up for each type. Pin severity to bugs, impact to features, your custom types, or whatever combination works for your team. You can also pin fields to issues that don't have a type.

Customize options and colors

Rename fields, add descriptions, create and reorder options, pick colors. Changes apply across the entire org instantly.

Control visibility on public repos

Issue fields work on public repositories. Set each field to Public (visible to everyone) or Organization only (visible to org members and collaborators only). All fields default to Organization only, so nothing is exposed unless you choose. Learn more.

🔍 Search by field values

Some things you can do:

• Find all urgent issues past their target date
• Surface high-effort features that haven't been started
• Filter by DRI to see someone's workload

📊 Works with Projects

Add any issue field as a column in your project views, then group, filter, and slice by field values. Unlike project custom fields, issue fields travel with the issue across projects and views, so your data stays consistent everywhere.

Issue fields count toward the 50-field limit per project.

Note: Issue field visibility settings are not currently supported in Projects. Support is coming in a future update.

📝 Timeline tracking

Every field change shows up in the issue timeline with what changed, when, and who did it.

⚡ API and automation

Full REST API and GraphQL API support for both field settings (create, update, delete fields) and field values (get, set, clear values on issues). Automate field management, do bulk updates, filter by fields, and sync with external tools.

Webhook events (field_added, field_removed) let you trigger GitHub Actions on field changes:

on:
  issues:
    types:
      - field_added
      - field_removed

✨ What's new since private preview

Since the private preview, we've fixed over 50 bugs and shipped several improvements:

• Effort field - added as a fourth default alongside Priority, Start date, and Target date
• Public repository support - issue fields now work on public repos with visibility controls. Set each field to Public or Organization only. Details
• Compact layout - fields use 40-50% less space in the sidebar
• Pin fields to no-type issues - fields can show on issues without a type
• Diacritics support - field names support accents, umlauts, and other special characters

🔄 Migration tool

Already using labels or project fields for structured data? We built a Copilot skill to help you migrate. It bulk-copies values from labels or project fields into your new org-level issue fields.

🙋 How to request access

Want to try it? Post a comment in this discussion with your organization slug and a brief description of how you'd use it. We'll get back to you.

💬 Feedback

We'd love to hear from you! Share feedback, report issues, or suggest ideas in this discussion. Your input directly shapes what we build next.

To learn more, check out the issue fields documentation.

[kutsan]

We use issue-only repositories internally to track tasks and manage everything through GitHub Projects. A single repository can have issues for multiple platforms and teams. This feature would help us streamline our workflow, so I'd like to request it be enabled for the @wavera org.

[labudis]

Enabled for wavera! Check your org settings to get started. Let us know how it goes!

[alexanderniebuhr]

We use labels to track over 500 issues for our innovation lab, would be great to get access to the preview @frickegroup

[labudis]

Enabled for frickegroup! Head to your org settings to configure fields. Would love to hear how it goes!

[alexanderniebuhr]

@labudis quick initial feedback. So far it looks quite promising, however sometimes we do add pull requests to our projects board and give them a priority. In the past it worked with project priority field, but there doesn't seem any option to set the new global priority field on pull requests. do you have any idea or insight?

[labudis]

For now Issue fields are an Issues feature so you will not be able to apply Issue fields to PRs but we are monitoring requests for PR support so your feedback is noted!

[aaronsteers]

@labudis and @alexanderniebuhr

+1 for support for custom fields for pull requests. One idea to implement would be to align "pull request" as an "issue type" - so that fields could have an affinity to be leveraged in pull requests (or not) in the same way that fields might be applicable to bugs-type issues or not.

[MrLesk]

Would like to explore storing Backlog.md's tasks directly as Github issues. This new feature would drastically simplify the integration
https://github.com/MrLesk/Backlog.md

[labudis]

Thanks for the interest! Issue fields are an organization-level feature, so they need to be enabled on a GitHub organization (not a personal account). Do you have an organization where you'd like us to enable it?

[DerZade]

Currently at @arma-events we use fields in projects and issue type, but the integration of issues and projects always lacked a bit imo. Atm we move all isses to a single project to allow setting some metadata like size, status etc. Would love to try out the more issue-centered approach.

Also: Is there any chance of multi select coming as a field type? I always missed that in projects and the only reason why we still use good old labels for some things (for example affected components) 😕

[labudis]

Enabled for arma-events! Check your org settings to get started. On multi-select, it's on our radar but not available yet.

[setchy]

+1 for multi-select.

I'd like to migrate from custom labels to Issue Fields for Platform: [macOS, Windows, Linux]

[msune]

+1 for multi-select

[kutsan]

It would be really nice if these and other fields (like type, milestone etc.) could be marked as required at the time of issue creation.

[labudis]

Required fields are on our horizon! Can you share a bit more about your use case? Understanding which fields you'd want to enforce and in what scenarios would be really helpful.

[fnesveda]

This looks great! Can we get it for the apify organization? 🙏

[labudis]

Access has been enabled for apify. You should now see Priority, Effort, and date fields on your issues. Let us know how it goes!

[pedro-vbai]

We'd love to try these! Org is voicebrain. We're just setting up project management in github and want to use Projects as a flexible, light-weight, de-centralized way to track, manage, and visualize groups of related issues. But we need certain metadata to be consistent across new Projects, such as priority, estimates, resolution reason, etc. It'd be awesome to have org-level metadata fields like these to handle this, since some of these fields won't work well as labels (and would make our labels much too crowded). Thank you!

[labudis]

Access has been enabled for voicebrain. You should now see Priority, Effort, and date fields on your issues. Let us know how it goes!

[labudis]

Hi @pedro-vbai! Just a heads up, we also just shipped visibility settings so issue fields now work on public repositories too. Organization admins can choose which fields are visible publicly and which stay internal. Details here.

[h-m-f-t]

These look like great additions! We'd love to try them out @cisagov.

We have some fields (priority, effort) in Project metadata that really make more sense on the issue. Structured issue metadata is likely the nudge we'd need to start actually using Issue types.

[labudis]

Access has been enabled for cisagov. You should now see Priority, Effort, and date fields on your issues. Let us know how it goes!

[amenity]

🎉 Congrats, @labudis! You've done a fantastic job moving this forward and collecting such thorough feedback.
I assume that since @cityofaustin already has private preview access, we don't need anything switched on, but if not, please hook us up. 🙏🏻

Are y'all still thinking that you'll be opening these to public repos by next week? We're in a bit of a holding pattern since migrating from Zenhub and are very eager to get our product ops reporting up and running again.

[labudis]

Access has been enabled for cityofaustin. You should now see Priority, Effort, and date fields on your issues. Let us know how it goes!

[labudis]

Great news, @amenity! Issue fields now work on public repositories. Organization admins can control which fields are visible to everyone and which are restricted to organization members. Details in this comment. No more holding pattern!

[nicosammito]

We’d love to request access for the @code0-tech organization. We are currently in the process of building our community and want to ensure a structured workflow from the start. Moving away from label-based workarounds to typed, org-wide metadata like Priority and Effort would be a huge help in streamlining our issue management and reporting.

[nicosammito]

Amazing, thank you very much 🔥

[labudis]

Access has been enabled for code0-tech. You should now see Priority, Effort, and date fields on your issues. Let us know how it goes!

[chriswnek]

As the PM for the argc org, a consistent way to add priority and effort across our repos would be amazing.

[labudis]

Thanks for the interest! I wasn't able to find an organization matching argc. Note that issue fields is only available to GitHub Organizations, not personal accounts. Could you double-check the org slug and share it here? Happy to get you set up.

[chriswnek]

@labudis Sorry, had a typo in there, it's agrc

[chriswnek]

@labudis Just bumping up this request for agrc so it doesn't get lost. Thanks!

[labudis]

thanks, I added this to be enabled tomorrow!

[labudis]

Access enabled for agrc! Priority and effort fields are now live across your repos. Enjoy!

[noraa-junker]

I personally do not understand why these are bound to an organization and not per repo. In an organization with many different repos the need for different issue fields can be very big. Please make this bound to repos and not organizations!

[noraa-junker]

It's not having a single set of fields across my organization that's difficult. It's more that certain repositories have specific needs. For example I am a contributor and close collaborator in the Microsoft PowerToys project. This is an app that consists of many different modules and it would be useful to have an issue field "Module" where we can specify the module. But as this feature is only available on organization level (Microsoft) such a field will (very likely) not be introduced as it is of zero use for other repos.

Maybe a hybrid approach where both is possible could be an option?

[kwin]

Same need for large organizations like apache, where each repo is run by a different team usually with different demands for issue fields

[kutsan]

Completely agree with @noraa-junker, we also need this for the same reason.

[phifuh]

When reading this i thought about the 2 most upvoted feature requests inside the repo discussion:

https://github.com/orgs/community/discussions/4174
https://github.com/orgs/community/discussions/41348

Grouping repos could work very well with "global" issue fields

[setchy]

Would love to try this for gitify-app 🙏 🚀

[jamietanna]

Ah, we must have missed that in the original announcement - I didn't realise it would only work for private repos for now. Out of interest, why the split between public/private repo support?

[labudis]

Access has been enabled for gitify-app. You should now see Priority, Effort, and date fields on your issues. Let us know how it goes!

[labudis]

Hey @setchy! Issue fields now work on public repositories. Your organization admin can control which fields are visible publicly and which stay internal. Details here. You should be unblocked now!

[setchy]

Awesome, thanks @labudis.

Is there plans on the roadmap to support filtering repository Issue Lists using the Issue Fields? ie: show me all Priority: High issues

[labudis]

Yes, this is on our radar. In the meantime you can filter by typing "Priority" in your search bar and picking "High" from the dropdown.

[vnagendra]

Could you please enable issue fields for https://github.com/organizations/termtegrity. We envision using this as follows

1. Use an issue field (number) for Estimates
2. When they show up in the Projects have a Grouped by/Swimlane Estimate + Repository + Assignee (3 different boards)
3. Allow developers to create their own boards if they want showing just their view

This will remove dependency on excel or markdown etc., where we keep track of estimates and figure out who has what pending work etc.,

[aconsuegra]

Issue fields are now enabled for termtegrity. Check your org settings under Organization > Planning > Issue Fields to get started.

Docs: Managing issue fields

[labudis]

Issue fields are now enabled for termtegrity. Check your org settings under Organization > Planning > Issue Fields to get started.

Docs: Managing issue fields

[kewisch]

@labudis I know you have a lot of comments to read here and appreciate your support. I reported a few issues and a request in https://github.com/orgs/community/discussions/189141#discussioncomment-16542939 that I just wanted to make sure didn't get lost. Apologies for the extra noise if you've already seen my comment previously.

[labudis]

Thanks for the follow-up, and for the detailed bug reports. I've seen both comments and they haven't gotten lost.

• Issue fields on PRs in projects: Known issue. Issue fields aren't supported on PRs, so they shouldn't render there. We're tracking this.
• Public/private field visibility in public projects: Good catch on the interaction between field visibility and project visibility. We're aware of the friction here and working on improving it.
• Naming conflict error: Thanks for the repro steps. We'll look into making that error message clearer.

Appreciate the thorough testing!

[jerrod]

Could the https://github.com/organizations/arqu-co org be enabled for the Issue Fields preview?

Context: we just finished a large Jira → GitHub Issues migration into arqu-co/issues (~7,500 issues across 6 Jira projects). Each issue is a member of a per-Jira-project board (e.g. https://github.com/orgs/arqu-co/projects/15) with project custom fields (Jira Created, Jira Resolved, Priority, Slack Reporter, etc.) populated by our migration scripts.

We want to lift those values up to org-level Issue Fields so they're queryable from the issues search bar with autocomplete — currently field."Jira Created":<2026-01-01 only partially indexes against project custom fields and the search bar doesn't suggest the field name. Backfill script is already drafted; we just need the preview enabled to create the org-level fields.

Thanks!

[labudis]

Issue fields are now enabled for arqu-co. Check your org settings under Organization > Planning > Issue Fields to get started.

Docs: Managing issue fields

[Neodevils]

I found a bug. When you add Fields inside the projects with importing; it doesn't show up inside the PR it's select options.

[labudis]

Thanks for reporting. Issue fields are currently only supported on issues, not pull requests. When a project contains both issues and PRs, the field options won't appear on PRs. This is a known limitation we're tracking.

[Neodevils]

Thanks for reporting. Issue fields are currently only supported on issues, not pull requests. When a project contains both issues and PRs, the field options won't appear on PRs. This is a known limitation we're tracking.

Somehow target date is working but select menu items are not working as I showed, hope it will be there or fully removed.

[macgillm]

Hi GitHub team,

We’d like to request access to organization-level Issue Fields for our boostCX organization:

https://github.com/boostCX

We’re working to streamline planning and triage across multiple repositories using GitHub Projects. Today, managing the same planning metadata separately in project fields across repositories is repetitive and difficult to keep consistent.

Organization-level Issue Fields would help us by:

• standardizing shared issue metadata across repositories
• reducing duplicate field setup and manual syncing
• improving planning and reporting in GitHub Projects
• supporting a custom intake and triage workflow we are building on top of GitHub Issues and Projects
• This capability would make it much easier for us to manage work consistently across our repositories and use GitHub Projects more effectively as a central planning surface.

If possible, we’d appreciate having this feature enabled for boostCX, or guidance on whether there is a beta, waitlist, or eligibility requirement we should follow.

Thanks for your help.

[labudis]

Issue fields are now enabled for boostCX. Check your org settings under Organization > Planning > Issue Fields to get started.

Docs: Managing issue fields

[perranpengelly-drdr]

Hi, could you enable this for wearedrdoctor please? Initial use is for priority and effort. We looking to migrate from Jira and have fields there for Product, Customer, Team etc. Some of these may work in a single select (although some may have to wait for multi select)

[labudis]

Issue fields are now enabled for wearedrdoctor. Check your org settings under Organization > Planning > Issue Fields to get started.

Docs: Managing issue fields

[abdelrahman-mohammad]

Suggestion: Multi-select type for issue fields.

I have an issue field called Area, and I constantly find myself needing to have two or more areas on a single ticket. Currently, there is no way to select multiple values for a given field for an issue. Therefore, I have to resort to labels for this type of labeling, which feels like issue fields should solve.

[broccolinisoup]

👋🏻 Thanks for the suggestion! Yes, multi-select issue fields are on our radar but not available yet.

[oliviertassinari]

Can we have those on pull requests, too?

[broccolinisoup]

👋🏻 For now, Issue fields are only available on Issues but we are monitoring requests for PR support so we noted your feedback! Thanks!

[Norbiros]

Hi! I have some feedback and feel it might be easier to discuss it on a quick call-would that be an option?

[dubeyarjun]

This feature lets you add custom structured fields (like dropdowns, text inputs, labels, etc.) to issues instead of relying only on free-form descriptions. It’s especially useful for:

Bug reports (severity, steps, environment)
Feature requests (priority, category)
Project tracking (status, owner, type)

Since it’s in public preview, it means the following: You can use it right now. It may still change or improve based on feedback; It’s not fully finalized/stable yet

It's a big step toward making issues more organized and consistent, especially for teams managing large projects

[dgxo]

Would love to implement this with our internal bug & task tracker to replace our project fields: @dovedalerailway

[broccolinisoup]

👋🏻 Issue fields are now enabled for dovedalerailway . Please check your org settings under Organization > Planning > Issue Fields to get started.

Docs: Managing issue fields

[kswartz26]

I would appreciate the opportunity to try this feature out. My goal is to migrate away from jira and do all issue tracking, planning, and prioritization within github. @oneroadsoftware

[broccolinisoup]

👋🏻 Issue fields are now enabled for oneroadsoftware . Please check your org settings under Organization > Planning > Issue Fields to get started.

Docs: Managing issue fields

[djpsychofogbear]

hi @labudis 👋 could we get these enabled for wasaico?

[broccolinisoup]

👋🏻 Issue fields are now enabled for wasaico . Please check your org settings under Organization > Planning > Issue Fields to get started.

Docs: Managing issue fields

[amenity]

Oof... so now that these are available in public repos, why aren't they available in public projects?

[broccolinisoup]

👋🏻 Thanks for your question! We're aware of the friction here and working on improving it.

[amenity]

Thanks, @broccolinisoup 🙏 ... it's so counterintuitive to me that everything is released to private repos/projects first, given that GitHub was once such an icon of open source. It's sad that we have to wait because we're sharing our code and working transparently.

We take pride in working transparently. Moving to GitHub Projects from Zenhub was very much driven by the desire to make our work more navigable to our leadership, City Council, other civic tech teams, and the residents we serve.

[amenity]

@broccolinisoup, How are you working to address the friction? We've already spent significant energy testing and planning around the use of issue fields; investing additional time into configuring issue fields, updating our product-ops docs, and re-training our team if there aren't plans to make them available in public projects. 😞

[rasi]

Can you please enable issue fields for org rasilab? Thanks!