ok except going back to my use case - I can't have Status and there is no iteration field type for issue fields?

We are exploring a way to make status an org-wide construct - watch this space!

ok except going back to my use case - I can't have Status and there is no iteration field type for issue fields?

We are exploring a way to make status an org-wide construct - watch this space!

@labudis Any ETA or confirmation on this feature? And in case this will be coming then it will be part of issue fields or separate feature like issue type and issue field and issue status?

@beingminimal Unfortunately, I don't have an ETA for this but it will most likely be a separate feature which spans Issue fields and Projects, creating a new mechanism for managing status and keeping it in sync.

We would love to try and give feedback so please let us know when it's ready to test even if in alpha. Thanks

Is there a plan to release an Iteration type to the available (limited) list of project custom fields?

Hello! We are using Github for both product managers, designers and the Dev teams.
With workflows and automation to plan the tasks, to show management roadmaps and planning, and to also monitor the dev teams.
Besides getting messy in the custom fields view because we have a lot (estimations vs real time, design fields, pm fields, dev fields) with the custom fields, some automation cant be triggered because custom fields don't trigger changes, but issue fields should, as far as they do today.
I'm rebuilding all of our work flow and views, and this will give me so much flexibility for this complex management.

Thank you for sharing! We have just enabled Issue fields for the melta-team organization. You can head to your Organization settings to start configuring them. Let us know if you have any feedback or need assistance.

First of all I wanted to thank you it is a game changer for me as I am the new product manager and I am rebuilding the board in the best of my ability and the issue fields are Game Changer due to the API and the events!!

I find myself that I have to put everything there so it will trigger, which is slightly besides the point but greatly helpfull!

For issue types I use epics and users stories and tasks and bugs and features and then I have different fields for each which is amazing and it helps me declutter a bit the project fields... but the one thing I miss most is the status update which I am now thinking of trying to integrate into the issue fields anyway instead of having a trigger that runs once in x time...
If you have any points of you on that subject that will help!!

other features I'd love to have

1. I would love to have a default value (forgort to write it in the docs review)
2. Grouping for all or.some of the fields to make it look more like the project custom fields to take up less space on the screen
3. General issue fields- even if an issue type was not selected...

Thanks again!! 🙏🏼🙏🏼

That's fantastic feedback, thank you @Eve-Yesodot!

1. That's an interesting suggestion - would you mind expanding on the use case there?

2. I have good news regarding "grouping" as we are already working on a much more compact "grouped" version of issue fields in the sidebar which will look and feel much more like Project fields.

3. We are also working on the ability to pin issue fields to issues without a type.

Please continue sharing feedback as it really helps us make the experience better :)

2 3 woohoo, amazing!🙏🏼🙏🏼👏🏼👏🏼 Any timeframe?
In 1 I meant lets say, as I use the issue fields for basically EVERYTHING 🫣 even status (cuz of the events) so if my issue type (out of Epic, User story, Task, Bug, feature suggestion) is user story or epic my default status will mostelly be let's say backlog.
Or, If it's a bug it goes to To Do...
Or let's say Phase  - Specs/Design/Dev.
If it's a user story, it's automatically sets Specs...
Just makes stuff slightly faster 😃

I have also logged your feature requests for multi-select fields, text field validation options (mobile, email) as well as PRs support. At this point we can't provide any estimates as we are still in the early stages of gathering feedback and don't yet have a full picture of the emerging feedback themes.

Thanks a lot! I’m aware there won’t be an ETA, but I appreciate you’re listening. Thanks!

@labudis Any chance we can get access for this also in case its available? Please let us know. Thanks github/roadmap#1086

That feature is planned but not yet in development. When it is there will be a similar discussion post to request access and share feedback.

That feature is planned but not yet in development. When it is there will be a similar discussion post to request access and share feedback.

Eventually issue fields can help to achieve this milestones across repositories, so is this feature also intended to support this? should we use in that manner also or not advisable? Please help to conclude. Thanks

Technically you could use an issue field in the place of milestones to achieve what cross-repo milestones would solve.

Create a new issue field of type "single-select" to track versions/milestones. Create a list of milestones as single-select values. When working on issues, apply the appropriate value based on which milestone the issue relates to. You can then find issues related to a milestone by filtering results in the Issues Dashboard search. You can also create saved views for each milestone in the Issues Dashboard for quicker access.

By no means this is the perfect solution, but might be worth trying out in the meantime.

Thank you for the suggestion - I noted this for our team.

@labudis This is the feature we need. Thanks

[Feature Request] GraphQL Issues

@labudis Currently it looks like there is support for Issue.issueFieldValues(first: number) in GraphQL. But there doesn't seem to be a Issue.issueFieldValuesByName(name: string) like there was for ProjectV2Item.fieldValueByName(name: string). Will this be added to the GraphQL API? Without it, making a good typescript API is harder.

Also for the IssueFieldSingleSelectValue there does not seem to be an optionId or value that points to the ID of the selected option. There is only a name. Since the name can change but the ID is permanent it would make sense that it is added. It is also weird that it is the only one with no value, while all the others do.

@labudis More feature request:

[Feature Request] Issue Fields Grouping

• Group a set of Issue Fields together. E.g. we have a bunch of Review fields which are all nearly identical:
  • Design Review, QA Review, and Product Review
  • All of these have the same SingleSelectOptions: Accepted, Rejected, In progress, and Requested
• It would be great if they appeared as one box like how Project fields are all in one box in the Issue Viewing UI
• It would be great if they could be added to pinned as a group to an IssueType

[Feature Request] Issue Filed Types

• Custom Numeric
  • For estimating points etc, it is nice having custom sequence: Fibonacci (1, 2, 3, 5, 8, 13), Powers of 2 (2, 4, 8, 16), Linear (default: 1, 2, 3) etc
  • These more naturally reflect how points are assigned in teams.
  • Often these should have a min, max. What does a negative estimate or really large one even mean?
• Multi-select
  • Allow multiple options to be selected

[Feature Request] XP iterations

• As stated above it would be great to have proper XP (eXtreme Programming) iterations like Pivotal Tracker used to provide.

@labudis Sorry for the long thread. One small bug found:

[Bug] Editing a Pinned Issue Field in Table View

1. Pin an Issue Single Select Field called $IF_A$ to a specific Issue Type called $IT_{pinned}$ but not to $IT_{not pinned}$.
2. Go to a a table view of project.
3. Ensure that an $IF_A$ is one of the visible columns and there are multiple issues of both $IT_{pinned}$ and $IT_{not pinned}$ in the table.
4. Use the inline table dropdown editor to set the value on $IF_A$ for $IT_{pinned}$
5. Try to do the same on $IT_{not pinned}$:
   • It should not work
   • BUT it does. Opening the ticket now shows the field on the right hand field values incorrectly
   • You can change it again in this view if you want
   • Removing it and the reloading makes the field dissapper

Thanks for the thorough report and for outlining the steps in detail! Just to clarify how the system is intended to work:

Pinning a field (like “Priority”) to an issue type is designed as a convenience for surfacing relevant fields during issue creation and when viewing issues—it’s not a restriction. Pinned fields make it quicker to access what’s important for a given type, but don’t prevent users from adding or updating any field on any issue within Projects.

So, even if a field isn’t pinned for a specific issue type (like “Priority” for “Task”), users can still edit and populate it via the table view, API, or GraphQL. This is expected behavior and allows for flexibility in how fields are managed across issues.

If you notice the UI behaving inconsistently (such as fields briefly appearing/disappearing after edits and reloads), that may still be a bug in the way field visibility or refreshing is handled—but not in the ability to set fields themselves. Please let us know if you have any questions or see something that doesn’t align with this intended approach!

Also thank you for sharing these feature requests. We will keep those in consideration!

Thank you, I'm glad you are enjoying it!

Thanks, we've enabled Issue fields for your org now! Let us know how you get on.

Sure thing! Please send me your org slug and I will get this enabled for you.

org;panin-sekuritas

Thank you.

Enabled now!

Enabled Issue fields for your org, please be sure to share any feedback or questions!

@cocoich how are you finding issue fields so far?

@labudis well, We are not using for now.
After discussing with my boss, my team decided to use it in this year's github Projects. We expect it to be easier to manage than the projects field I used before.

Enabled Issue fields for your org, please be sure to share any feedback or questions!

thanks - granted access. Let us know what you think!

thanks - granted access. Let us know what you think!

thanks - granted access. Let us know what you think!

At the moment it is not possible to create shared views of the Issues Dashboard as this page is designed to be user-specific.

A workaround might be to create a shared Project view which contains issues from multiple repositories, however, the suitability of this workaround highly depends on your setup. If you can share more details about what sort of views you would like to create and how your repos and Projects are structured I might be able to advise further.

The views we would be looking for would be driven by a need to see global totals for Issues that meet certain criteria. As in, "how many Issues matching X criteria do we have across all of the repos and projects"?

At this point, we're still determining the most logical way to structure our projects, but it would likely be one project per Team and the various repositories might need to be used in multiple projects.

Yeah, I totally get the use case, although you are discovering a separate gap in our Issues experience rather than something specific to issue fields.

This is very much a workaround rather than an ideal solution but if you have less than 10 repos theoretically you could set up a Global Project with "auto-add" workflows enabled for every repo that you want to roll up. That way you would have one big project that has all of your issues and you could then visualise the desired views there.

The workaround won't work in our scenario, but I appreciate you making the suggestion. Thanks for all of the help so far, and I'll continue to keep my questions/feedback focused specifically on trying out the Issue Fields preview.

No worries, I have logged your feedback for the broader team.

thanks - granted access. Let us know what you think!

Thanks @labudis!!

This is great, but why is it limited to 10 pinned fields. This seems an arbitrarily low number?

Thanks for your feedback, it's mostly to ensure that the Issue sidebar doesn't explode with an endless wall of fields. What would be a more appropriate limit for your use cases?

Not much more! We are migrating several Issue Fields so temporarily need 12 right now but then will go down again. But I can imagine anywhere between 10-20 would be the max. Though surely this is up to the company if they want to have way to many fields on an issue.

Got it, we will explore potentially lifting this limit.

Yes, you can order issue fields by going to Organization Settings > Planning > Issue types. Then pick your "Engineering" type and under Pinned issue fields, move the fields as desired by the drag handles. This order will then be respected in the Issues sidebar.

I do this, then click save, but it doesn't save?

Ah it looks like a regression, reported as a bug and we will work to fix this.

Are you using a single-select field type for storing dates or is this a date field? You can choose colors for single-select options but not for dates since they are dynamic.

It's a date field :/

got it! what sort of behaviour would you expect in terms of colours?

I'd expect different colors for different date fields. In our set up, we have 3 relevant dates: "Start Date", "End Date" and "Targeted Release Date". Having each be different and consistent throughout the project would be awesome, so people can inherently understand what each date is without hovering over them.

Customizing the colors would/could be nice, but doesn't really matter IMO - just that the colors are different

Enabled access! let us know how you get on

Access granted!

Thanks for sharing these examples, @fostimus! Having field options adapt based on type and conditional fields that appear contextually are both interesting ideas we've been thinking about. No commitments yet, but the scenarios you've described help us understand the need better. We'll keep this feedback in mind as we evolve issue fields.

Kind of a gnarlier ask, but I think would be really powerful: can single-select options change based on the field type they are pinned to? Here's our example:

'Domain' pinned to 'Engineering' makes a ton of sense for these options, but the 'Domain' options for something like 'Marketing', 'Product', etc will be wildly different.

Separately, adding some more colors to use for single-select options would be sweet as well, but not as needed!