Issue fields: Structured issue metadata is in public preview #189141
Replies: 301 comments 478 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@rodneyjoyce you should now have access, could you please confirm? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, thank you - it is working very well |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Estoy tratando de todavía implementar espérenme el paso . 🙏🏻 |
Beta Was this translation helpful? Give feedback.
-
|
We use labels to track over 500 issues for our innovation lab, would be great to get access to the preview @frickegroup |
Beta Was this translation helpful? Give feedback.
-
|
Enabled for |
Beta Was this translation helpful? Give feedback.
-
|
@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? |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
@labudis and @alexanderniebuhr
|
Beta Was this translation helpful? Give feedback.
-
|
Would like to explore storing Backlog.md's tasks directly as Github issues. This new feature would drastically simplify the integration |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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) 😕 |
Beta Was this translation helpful? Give feedback.
-
|
Enabled for |
Beta Was this translation helpful? Give feedback.
-
|
+1 for I'd like to migrate from custom labels to Issue Fields for |
Beta Was this translation helpful? Give feedback.
-
|
+1 for |
Beta Was this translation helpful? Give feedback.
-
|
+1 for multi-select. Has there been any progress with this? We'd like to use this for platforms as well. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
This looks great! Can we get it for the |
Beta Was this translation helpful? Give feedback.
-
|
Access has been enabled for |
Beta Was this translation helpful? Give feedback.
-
|
We'd love to try these! Org is |
Beta Was this translation helpful? Give feedback.
-
|
Access has been enabled for |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Access has been enabled for |
Beta Was this translation helpful? Give feedback.
-
|
🎉 Congrats, @labudis! You've done a fantastic job moving this forward and collecting such thorough feedback. 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. |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
-
|
Access has been enabled for |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Amazing, thank you very much 🔥 |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
-
|
Access has been enabled for |
Beta Was this translation helpful? Give feedback.
-
|
As the PM for the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the interest! I wasn't able to find an organization matching |
Beta Was this translation helpful? Give feedback.
-
|
@labudis Sorry, had a typo in there, it's agrc |
Beta Was this translation helpful? Give feedback.
-
|
@labudis Just bumping up this request for |
Beta Was this translation helpful? Give feedback.
-
|
thanks, I added this to be enabled tomorrow! |
Beta Was this translation helpful? Give feedback.
-
|
Access enabled for agrc! Priority and effort fields are now live across your repos. Enjoy! |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
Same need for large organizations like |
Beta Was this translation helpful? Give feedback.
-
|
Completely agree with @noraa-junker, we also need this for the same reason. |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
-
|
When reading this i thought about the 2 most upvoted feature requests inside the repo discussion: https://github.com/orgs/community/discussions/4174 Grouping repos could work very well with "global" issue fields |
Beta Was this translation helpful? Give feedback.
-
|
Would love to try this for |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
Access has been enabled for |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
Awesome, thanks @labudis. Is there plans on the roadmap to support filtering repository Issue Lists using the Issue Fields? ie: show me all 
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
This looks great! Would love to use it with |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
Access has been enabled for |
Beta Was this translation helpful? Give feedback.
-
|
Hi @ViewFromTheBox! Just shipped public repo support for issue fields. You can now use them on public repositories with visibility controls. More info here. |
Beta Was this translation helpful? Give feedback.
-
|
Please enable them for |
Beta Was this translation helpful? Give feedback.
-
|
Enabled for |
Beta Was this translation helpful? Give feedback.
-
|
To me, it makes sense to have Status as a locked issue field, rather than a locked project field. In my experience, issues have a universal status, rather than different statuses that apply to individual projects. |
Beta Was this translation helpful? Give feedback.
-
|
Also, when single selection options have descriptions (e.g, what each priority label "means"), is this information displayed to the person setting these fields on their issues. How are they supposed to know what each means if they are not an organisation admin? |
Beta Was this translation helpful? Give feedback.
-
|
Same here! I need the issue field to keep |
Beta Was this translation helpful? Give feedback.
-
|
Interesting perspective. We kept Status as a project field because different teams often need different workflow stages for the same issue (e.g., "In Review" in one project, "Blocked" in another). That said, we are considering expanding the built-in issue states beyond open/closed to recognize more granular stages an issue might be in. Appreciate the feedback, it's helpful as we think through this. |
Beta Was this translation helpful? Give feedback.
-
I agree that Status should be Issue scoped. "In Review" always means "In Review", "Blocked" is a relationship, rather than a Status. I have added "Issue Status" as a custom Issue Field, but obviously the Project Board layout is driven by Project Status, so this means I lose access to a valuable view. Might we be able to reconfigure the Project Board view to have columns based on a configurable field? It seems that there is inevitably duplication between Issue Fields and Project Fields, it would be ideal if we can connect these fields when desirable. |
Beta Was this translation helpful? Give feedback.
-
|
Can we have them in repos outside organizations? I hope this doesn't end up like "Issue type" |
Beta Was this translation helpful? Give feedback.
-
|
We're starting with organizations since that's where we see the biggest pain around coordinating metadata across repos consistently, but we're watching feedback for personal repos too. It's something we're considering. |
Beta Was this translation helpful? Give feedback.
-
|
Please allow an open source project to opt out of using and displaying this on the sidebar. It makes the interface too heavyweight (like Jira). |
Beta Was this translation helpful? Give feedback.
-
|
None of the starter fields are public by default, which means they won't be displayed to contributors. If you'd prefer to remove them entirely, you can delete issue fields from your organization settings. Here's how: Managing issue fields in your organization. |
Beta Was this translation helpful? Give feedback.
-
Then that should remove the sidebar section as well, which currently is not the case. The same issue exists for issue types: |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
I have an issue where the sorting is not updated in projects when updating the ordering of the field. |
Beta Was this translation helpful? Give feedback.
-
|
Is only solved by changing the field back and forth for the issue |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for reporting this. We're looking into the sorting sync between issue field option ordering and project views. It shouldn't require toggling values to update. I'll flag this internally. |
Beta Was this translation helpful? Give feedback.
-
|
Feature request OR question
|
Beta Was this translation helpful? Give feedback.
-
|
Right now, you can control field ordering through pinning fields to specific issue types. When you pin fields to a type, you can set the order they appear in. Here's the docs: Managing issue fields in your organization. Ordering for issues without a type isn't supported yet, but it's something we're aware of. |
Beta Was this translation helpful? Give feedback.
-
|
It would be helpful to support marking custom fields as mandatory during issue creation, along with the ability to configure default values. For example, when creating a bug, fields like Priority should be required to ensure essential triage information is captured. Admins should also be able to set default values where appropriate. |
Beta Was this translation helpful? Give feedback.
-
|
I agree. Project level fields do have the option of setting default values. It would be very useful (and encourage engagement) to pre-fill the issue fields with the most common settings/values. |
Beta Was this translation helpful? Give feedback.
-
|
Both of these are on our radar. Required fields during issue creation and admin-configurable defaults would help ensure issues have the right metadata from the start. Thanks for the clear use case. |
Beta Was this translation helpful? Give feedback.
-
|
Is there a way to reorder the Types under the default Issue Types? |
Beta Was this translation helpful? Give feedback.
-
|
Not yet, but we're aware of the need. Right now types appear in creation order. We'll look into adding reordering support. |
Beta Was this translation helpful? Give feedback.
-
|
It would be nice if we could change the ordering of the fields. |
Beta Was this translation helpful? Give feedback.
-
|
I think I found a bug. I edited the organization-global issue fields (deleted some of the default ones I am not using) and now even though all of the remaining ones are pinned to all issues (including those without a type) I can't add any of them as columns to a project. I had them as columns, but as soon as I started editing the fields, those columns vanished. What is required for an issue field to be able to be added as a column on a project? |
Beta Was this translation helpful? Give feedback.
-
|
Appears to just have been a momentary glitch, they've magically reappeared now... |
Beta Was this translation helpful? Give feedback.
-
|
Can we get workflows on these issue fields? The basic one would be for one that specifies the issue status, goes to a complete/done selection when the issue is closed. |
Beta Was this translation helpful? Give feedback.
-
|
I am currently unable to view or sort by these issue in my project. I can see them and set them on the Issues themselves, but can't make them visible in the Project fields and so i can't sort by then. Is this a known bug? |
Beta Was this translation helpful? Give feedback.
-
|
Issue fields do not work with GitHub Projects unless they're private. Microsoft tends to roll features out to commercial customers long before open source teams get access. 😢 Even if you have an enterprise plan, you're essentially penalized for working in the open for the public good instead of private |
Beta Was this translation helpful? Give feedback.
-
|
That's unfortunate. I guess i have to go back to my own custom priority field |
Beta Was this translation helpful? Give feedback.
-
|
They've been promising it's on the way for several months now! We're testing in a private project & waiting with bated breath. 🧘🏻♀️ |
Beta Was this translation helpful? Give feedback.
-
|
Is there any plan for gh cli to include native issue field support? I would like my agentic workflows to be able to modify the issue fields with gh commands. |
Beta Was this translation helpful? Give feedback.
-
|
Update: Issue fields now work in public Projects 🎉 Issue fields are now fully supported in public and internal Projects. If you add an issue field to a public project, it will respect the field's visibility setting:
A few details on how this works:
Manage field visibility in your org settings under Settings > Planning > Issue fields. Learn more about field visibility. |
Beta Was this translation helpful? Give feedback.
-
|
Cool! Wouldn't it make more sense to allow organization fields to be used for public projects, but make them visible only to organization members, rather than making them completely unusable in public projects? And does this apply to all public projects, or only those belonging to organizations? |
Beta Was this translation helpful? Give feedback.
-
|
Amazing!! 😊 👏🏻 Thank you, @labudis! |
Beta Was this translation helpful? Give feedback.
-
|
How do I turn this feature off? Who automatically turned this feature on for me? Why did you do that? I do not want this feature |
Beta Was this translation helpful? Give feedback.
-
|
seriously, how do I turn this off? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
issue.fields.public.preview.mp4
If you've ever used labels like
priority/p0,severity/high, orteam/frontendto 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:
📦 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:
Pinned to the right issue types by default
Create a bug and you'll see
PriorityandEffortright 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:
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:
📊 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.
Issue fields are fully supported in public and internal Projects. Field visibility settings are respected: only fields set to Public appear in public projects, while Organization only fields are automatically excluded.
📝 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:✨ What's new since private preview
Since the private preview, we've fixed over 50 bugs and shipped several improvements:
🔄 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.
Beta Was this translation helpful? Give feedback.
All reactions