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 for all organizations on GitHub.com and GitHub Enterprise Cloud. No invite or waitlist needed. Manage them in your org settings under Settings > Planning > Issue fields. Changelog

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
• REST API parity - set field values when creating issues via the REST API, matching existing GraphQL support
• Migration Copilot skill - bulk-copy values from labels or project fields into org-level issue fields. 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.

💬 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.

[rodneyjoyce]

Please give us access to this feature (https://github.com/organizations/DataDrivenAI/) - we use Priotity heavily in our Kanban board for our human and agentic development workflow.

[labudis]

@rodneyjoyce you should now have access, could you please confirm?

[rodneyjoyce]

Yes, thank you - it is working very well

[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.

[kutsan]

@labudis Sorry for my extremely late answer. Generally, we want to make fields required to ensure integrity across issues. For example, issues opened by product management should have a minimum set of fields they must fill in. As an example, in our project we link every issue to a milestone, and there shouldn't be any issue without a milestone. Required fields would ensure this.

[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.

[ViewFromTheBox]

This looks great! Would love to use it with ArtisanPack-UI!

[ViewFromTheBox]

@labudis It's been a day and I missed the part about an explanation. Right now I have a lot of labels that start with Priority::, Type::, Status::, Area::, etc., and being able to use this would be a much better way for us to organize those instead of using an absolute ton of labels.

[labudis]

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

[labudis]

Hi @ViewFromTheBox! Just shipped public repo support for issue fields. You can now use them on public repositories with visibility controls. More info here.

[dodyg]

Please enable them for silverkeytech. We keep track of everything using GitHub Issues.

[labudis]

Enabled for silverkeytech! Let us know how it goes.

[wesProg23]

They're coming to Project Views?

[amenity]

They're available if your project is public. Otherwise, issue fields don't yet work with GitHub Projects.

[labudis]

To clarify: issue fields work with private projects today. You can add them as columns in your project views. Public project support is coming very soon. Docs: https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/adding-and-managing-issue-fields

[wesProg23]

I got it. My repository is private, but the project was public (unecessarily), i changed to private and voilà

[garrettm]

Could we have access for org Ginger-Labs? We use GH Projects for our issue tracking and this has been a pain point for us for a long time

[twocaretcat]

You don't need an invite anymore as it's rolling out to everyone :)

Docs: https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/adding-and-managing-issue-fields

[labudis]

Yes, you should now have access.

[xKelvin]

Love this customizability! Additionally, support for languages other than English, such as Japanese, would be kind of nice.

Actually, I checked Issue types and it seems this is already possible there! So supporting other languages is nothing new and would love to see it extended to fields.

[labudis]

Great catch! We'll make sure there is parity with issue types here. Appreciate the feedback.

[MarcoCarandenteDCL]

With this now we have two different priority fields visible in an issue:

one we don't use that we can't remove (the "out of the box"):

and the one that we actually use:

when it comes to making a new issue, we are presented only with the inbuilt priority field and not the one we want:

please give us the ability to disable your own default stuff.
Also, it's very hard to make any habit/procedure with GitHub constantly shuffling around basic things and adding/removing UI elements or steps to the workflows for no apparent reason. Please stick to something for longer than two months.

[thclark]

I had the same issue, @labudis - ended up with multiple Priority labels and my team got confused over priorities. 25 minutes was the elapsed time between someone first seeing this appear and someone getting confused.

Overall, I think it's poor practice to randomly introduce a set of defaults, when you know that a significant number of users will already have something looking like - but not quite the same as - that default already.

When GitHub introduced cross-repo projects, there was a process where you could create a new project from a template. So you could see the new functionality was there ("Try the new projects"), you could get started immediately ("Start with a template"), but it wasn't the case that suddenly all our repos had a new project and we just had to figure it out. Isn't this an SOP at GitHub? Teach users that a feature exists and allow them to adopt it in an accelerated way, but don't simply deploy it in a way that might break users' workflows.

[labudis]

We appreciate the candid feedback and understand the frustration when something new shows up unexpectedly in your workflow. With default fields we're introducing a primitive that's been missing for a long time, and we recognise that requires adjustment for teams who already have things working well. We believe typed metadata for things like Priority is ultimately a better foundation than labels or project-level fields, but we also know the transition needs to be smooth. We built a Copilot skill to help migrate that bulk-copies values from labels or project fields into org-level issue fields, and we're actively working on further improvements to reduce friction. If you'd rather restore your prior workflow now, you can delete the default issue fields in org settings (Settings > Planning > Issue fields).

[labudis]

Issue types were introduced in January 2025 and are system-level metadata on issues. The type picker isn't removable because types are foundational to how issues work going forward; they drive which fields appear, enable filtering and search by type, and allow GitHub to build richer workflows on top of them. If your team doesn't use types actively, you can leave it unset when creating issues.

[tomasMizera]

Hi @labudis, do you have any recommendation when to use project fields and when issue fields? Will GitHub now offer both ways or discontinue one?

It feels like org-level issue fields are the correct way to move forward, project-wide ones always felt a bit .. meh .. Any plans to rename "issues" to something that does not sound like a bug? An issue can now have type "enhancement" 🤯 You already call it "tasks" in projects.

[labudis]

Issue fields are org-wide metadata that live on the issue itself and sync to any project the issue is in. Project fields are scoped to a single project and useful for project-specific context (like a sprint column or board status) that doesn't need to follow the issue everywhere. Both will continue to exist; they serve different purposes. Issue fields for shared, durable metadata; project fields for view-specific or workflow-specific data.

No plans to rename "issues" at this time, but we appreciate the thought!

[venpopov]

Programmatic / API support for type-to-field pinning

The preview currently exposes full REST + GraphQL coverage for issue-types, issue-fields, and field values (create / update / delete) — but field-to-type pinning can only be configured through the web UI. Both IssueFieldCreateOrUpdateInput and UpdateIssueTypeInput reject pinning arguments; no pinFieldToIssueType mutation exists in the schema; the IssueType.pinnedFields field is read-only.

This is the load-bearing affordance of the whole feature — types and fields without per-type pinning are just labels with a typed-options column. For org-wide migrations or any automation flow that creates types + fields + pinning in one shot, the UI-only step is the bottleneck that forces a human into an otherwise scriptable loop.

Specific asks (in order of usefulness):

1. A pinnedTypes input on createIssueField / updateIssueField (or symmetric pinnedFields on createIssueType / updateIssueType) accepting an array of type IDs.
2. A standalone pinIssueFieldToType / unpinIssueFieldToType pair, useful for incremental adjustments without re-asserting the full set.
3. REST equivalents: PUT /orgs/{org}/issue-fields/{field_id}/pinned-types/{type_id} and the inverse DELETE.

Context. We just migrated an org (vade-app, 141 open issues across 9 repos) from label-encoded structured metadata (type:* / prio:* / readiness:*) to native types + fields. The schema mutations and per-issue backfill were both scriptable; only the pinning step required clicking through the UI per field × per type. For a fresh adopter following an automation-first workflow, that single non-programmable step is the friction point.

[labudis]

Agreed, pinning via API is a gap we need to close. Tracking this.

[venpopov]

Cool! Thanks for the quick pickup. It would make us really excited to remove those manual steps from ourknworkflows!

[irwandj]

This is really great news!

[emilygorelik]

It would be great if we can have a way to add the Priority as a badge on the card view for the Board project view. Something like the following:

[NovaCat35]

Agree, this would be a much-needed QoL improvement to ticket management

[labudis]

Noted, we're tracking this. Appreciate the feedback!

[labudis]

🎉 Issue fields are now available to all organizations on GitHub.com and GitHub Enterprise Cloud. No invite needed, no waitlist.

Every org now has four default fields (Priority, Effort, Start date, Target date) ready to use. Customize them in your org settings under Settings > Planning > Issue fields. Full changelog here.

Thank you to everyone who participated in the preview and shared feedback. It directly shaped what we shipped. Keep it coming!

[ekolis]

This looks like a really useful feature. Why is it limited to organizations? Is it a paid premium feature only available to enterprise customers, or is it being rolled out to organizations first and all other repos later?

[soroushm]

😍 Love it, Keep the platform Secure and Up 🫶

[diegomanuel]

First of all, thanks for the great effort to support this feature! 👏
It woud be nice to also have the support to define the issue fields but at repo level.

Not all repos inside an organization and/or a project have the same issue fields.
Even a repo could be part of an organization but not having any project attached to it.

Right now I have duplicated fields for any issue inside a repo that's also part of a project:

• The project has a total of 3 repos attached and we want to have those project fields in all its repos (this is working great as it is).
• Don't need/want those 3 repos to have "their own fields" inherited from the organization (this is the problem).
• Still want to have the "organization-level fields" for any other repos in the org (the default behaviour for any org's repo).

Thanks in advance!

[dominicafonso-datum]

issue fields for start and target date are similar to project fields start and end date. can we make the issue field act as the project field please? in the project field input we could have a button to "use issue field"

[aidar-darmenov-livatek]

Could you please consider more levels of escalation in Effort? 3 levels don't seem to cover the whole spectrum. We use something like this

Levels:

• L1 - basic task, e. g. CRUD
• L2 - task, that requires analysis and probably, understanding of context
• L3 - task, that requires analysis, understanding of context, that could cause complex problems if executed incorrectly
• L4 - task, that requires deep analysis of the problem and decent expertise, understanding of context, that could cause
  complex problems if executed incorrectly
• L5 - task, that requires deep analysis of the problem and decent expertise, understanding of context, that could cause
  complex problems if executed incorrectly, affects whole project

[Exac]

The default fields should not be Start date and Target date. Effort is fine.

Most projects have a massive backlog of issues. Adding start dates and target dates is wasted for most tasks that are not able to be started straight away. Make these optional, but since GitHub doesn't have a concept of whether a task is in progress, adding start and target dates is meaningless. If you change the UX for Start date to be more of a button that can toggle between start and pause initial states then the date the task was started can be shown. But naming the field "Start Date" and showing a calendar control is alarming to me.

Every team I've been on for the past 15 years has used Agile. We should respect that WRT the UI.