Issue fields: Structured issue metadata is in public preview · community · Discussion #189141 (original) (raw)
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.
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:
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
- Public project support - issue fields now work in public and internal Projects, with visibility settings fully respected. Only fields set to Public appear in public projects; Organization only fields are automatically excluded
- MCP remote server support - list, filter, set, and clear issue field values via the GitHub MCP remote server (
https://api.githubcopilot.com/mcp/). Works with any MCP-compatible client. Details
🔄 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.