Evolving GitHub Issues - Public Preview

[github-staff]

GitHub Issues is evolving! 🥳

💬 Feedback wanted

Thank you for participating in the issues public preview for sub-issues, issue types and advanced search.

To provide your feedback on other experiences released at the same time, please visit:

• Sub-issues Public Preview #148714
• Issue Types Public Preview #148715
• Advanced Search for Issues Public Preview #148716

This new functionality is built on top of a UI rewrite of issues, which we would love your feedback on!

The aim of this rewrite was to clear up technical debt, allowing us to move faster in bringing new functionality to issues. With this in mind our goal has been parity with the existing experience. It should feel very familiar with only a few minor cosmetic tweaks.

The experiences that have been included so far in these updates are:

• The repository issues index
• The main issue body
• The issue creation experience

The milestones, labels and /issues dashboard pages have not yet been migrated.

Please leave your feedback below on what is working well, any bugs you encounter, and what else you'd like to see!

🛠️ Things we fixed

We're listening to your feedback and working hard to address the highest priority issues. Below is a list of bug fixes and enhancements that we rolled out since we launched the Public Preview.

🛠 Bug fixes:

• In certain repositories, running a search would navigate to the Issues page
• Some users couldn’t view the Issues Index
• Broken navigation for some users
• Focusing on the title input when creating an issue
• Closed (not merged) linked PRs showing as drafts in the development picker
• Pagination on the Issues Index causing elements to jump
• Ability to perform exact searches in Issues
• Some assignees not appearing in the assignee search
• Checklist indentation
• Previously created issue text should no longer be visible when creating subsequent issues
• Accessibility: list items under menu button are not selectable through keyboard
• Accessibility: 'More Action' controls are not keyboard accessible
• Accessibility: The 'move up' and 'move down' controls are not accessible through their defined shortcut keys
• Going from modal to full-screen was not retaining issue progress. Now the transition is seamless
• Users are no longer able to create blank issues when blank issues are disabled
• Ability to clear milestones in bulk
• Issue edit diffs are now easier to read

✨ Features & Enhancements:

• Bypass templates: Automatically bypass template selection if there’s only one template and blank issues are disabled
• Milestones: Create milestones directly from the milestone picker by entering a new milestone name
• Switch templates: When creating issues, view the selected template and quickly switch to another one if needed
• Required fields: You can now specify required fields on issue forms in private repositories, which ensures that contributors provide essential information before submitting an issue.

Closing Discussion Notice

As we've shipped the GA for Issues today, we are closing this discussion. Please direct all Issues and Projects feedback in the Evolving GitHub Issues and Projects (GA) discussion. Thank you!

[mcanouil]

Parsing of code blocks in issue templates within the new GitHub Issues is broken. (see the bottom of the screenshots)

Additionally, as you can see at the top, the name of the template and its description is no longer displayed in the preview of the new issues.

Preview	Current

Using extra backticks or indentation leads to different parsing issue in the preview. (None allows to get proper display as without the new GitHub Issues)

Extra backticks block

Indentation block

name: Bug report description: Report an error or unexpected behavior labels: [bug] body: - type: markdown attributes: value: | You can share a Quarto document using the following syntax: `````markdown ````qmd --- title: "Reproducible Quarto Document" format: html engine: jupyter --- This is a reproducible Quarto document using `format: html`. It is written in Markdown and contains embedded Python code. When you run the code, it will produce a message. ```{python} print("Hello, world!") ``` {#fig-placeholder} {{< lipsum 1 >}} A reference to @fig-placeholder. The end. ```` ````` - type: textarea attributes: label: Bug description description: Description of the bug. placeholder: Please describe the bug here.

name: Bug report description: Report an error or unexpected behavior labels: [bug] body: - type: markdown attributes: value: | You can share a Quarto document using the following syntax: ````qmd --- title: "Reproducible Quarto Document" format: html engine: jupyter --- This is a reproducible Quarto document using `format: html`. It is written in Markdown and contains embedded Python code. When you run the code, it will produce a message. ```{python} print("Hello, world!") ``` {#fig-placeholder} {{< lipsum 1 >}} A reference to @fig-placeholder. The end. ```` - type: textarea attributes: label: Bug description description: Description of the bug. placeholder: Please describe the bug here.

Original issue template for the screenshots: https://github.com/quarto-dev/quarto-cli/blob/main/.github/ISSUE_TEMPLATE/bug_report.yml

[boazreicher]

Thank you for reporting this. We can reproduce the issue, and are currently looking into it.

[boazreicher]

Hi @mcanouil, we've rolled out the fix for this. Please let us know if you still encounter any issue.

[mcanouil]

Thanks, it works!

[labudis]

@mcanouil Just wanted to update you that we have addressed one of your feedback items related to the display of the Issue Template. Now, you will see the chosen template in the Issue Creator and even have the option to change it while creating the issue, in case you change your mind.

Please let me know if it works as expected :)

[mcanouil]

Thanks, that's great.
It simplifies the workflow to switch between templates in case of miss-click.

[karlhorky]

Copying my comment from discussion 139935 (cc @alondahari @labudis):

---

Linking to a text fragment does not work with the new GitHub Issues UI, reproduction steps:

1. Use a browser that supports linking to text fragments (eg. Google Chrome)
2. Visit a page with the new GitHub Issues UI (eg. Preflight Docker container with PostgreSQL database: opts.uid is NaN upleveled/preflight#588)
3. Select some text on the page, right click and select "Copy Link to Highlight" (see screenshot below)
4. Visit the example link
5. 💥 Observe that the page either scrolls to the wrong position and does not highlight the text

Expected (old GitHub Issues UI)

Example link:

https://github.com/lovell/sharp/issues/4247#:~:text=provide%20sample%20image(s)

Correct scroll position, highlighted "provide sample image(s)" text:

Actual (new GitHub Issues UI)

Example link:

https://github.com/upleveled/preflight/issues/588#:~:text=We%20need%20to%20investigate

Incorrect scroll position, no highlighted text:

---

Also, copying the comment on my discussion thread by @MasterInQuestion:

The janky anchor navigation is far more pervasive...
    github.com/orgs/community/discussions/139935#discussioncomment-11058053

[labudis]

@karlhorky thanks for flagging this again! We are aware of this issue but we are working through a large backlog of ideas and suggestions and this particular fix has not yet reached the top of the priority list. We do consider every piece of feedback that comes from the community so please keep highlighting anything that could be improved - it truly helps!

[MichaReiser]

Copying my comment from the previous discussion

---

We're still using the legacy issue template workflow because we want only a single template with some pre-defined content in the description. We don't want users to have to select a template.

We noticed that the issue template no longer works after opting into the public beta. Now, I'm mainly curious to understand if this is intentional because the workflow is considered legacy or if you plan on bringing back support for legacy templates, and we can keep using it. Thank you

[MichaReiser]

Oh nice. Thank you! We'll give it a try.

[MichaReiser]

@boazreicher This feature has now regressed with the new "modal". It now always shows a modal even if there's only one issue template.

[boazreicher]

Thanks for reporting @MichaReiser, we'll take another look at this.

[labudis]

@MichaReiser this has been fixed now. Please verify.

[badeball]

Please verify.

Still doesn't work, can be seen eg. here.

[janbrasna]

I'm not sure what is actually part of what "experience"/preview, as this discussions space doesn't really make it easy to navigate and understand how it all relates together, with announcements posted as "unanswered questions", and messaging from staff indistinguishable from any other content amidst emoji explosions in categories and labels looking like unicorn barf of color and shapes and other myspace-esque qualities that probably only make sense to folks under the legal drinking age… so sorry if I'm not posting in the right thread, but they all look quite alike, with some of the boilerplate text of announcements recycled, esp. wrt what's in scope and what not, that seems to be identical across the threads, so you've effectively lost me there;)

1. I've noticed there's some "preview" without any info, feedback link, or opt-out (incl. in settings):

• Issues showing "Preview" badge with no additional context taking up valuable space #149146

2. Not sure if the new editor UI is also part of this, can't find the same as above (missing preview info, opting out of the experience, and a link to feedback) to post under the announcement/feedback there, so made a new thread:

• Issue composing textarea feedback #149149

[labudis]

@janbrasna Thank you for sharing your feedback and I'm sorry to hear you did not find our communications clear. It's one of the largest public previews in recent GitHub history touching many parts of the Issues experience and whilst we strive our best to communicate clearly, there is always scope to do better and we take your comments on board.

Regarding the scope of the release, it impacts virtually every part of the Issues experience. We focused on improving the performance and usability of the new issues experience whilst keeping it as similar as possible to the classic Issues experience that our users know and love. In addition, we have added three completely new features: sub-issues, issue types and advanced search.

I will respond to the two specific pieces of feedback in their respective discussion threads.

[janbrasna]

Oh no worries Tadas, I'm just probably not wired to navigating the discussions space for feedback purposes;) and failed to find the appropriate threads instead of submitting new ones. Hopefully it's relevant to what you've been working on — thanks for taking a look, appreciate what you do here!

we have added three completely new features

Great job with those major features, hat tip!

[janbrasna]

What specific improvements does the user suggest for better clarity in announcements or feedback threads?

Funnily enough, it's e.g. hard to tell apart content from GH staff, compared to others once it gets a bit noisier like here — so if this inquiry comes from a Hubber I'd be happy to elaborate a bit more if you're interested, nonetheless I see no sign that this particular user is "staff" to begin with.

(E.g. I'd like to unsubscribe from all other notifications from other comment threads, and only get pings for the reply threads on comments I've participated; and/or only staff responses instead of getting pings throughout the day of everyone adding to the feedback etc. — but there's definitely more, happy to share a user's PoV from the experience of several years using the discussion space as a landing page for feedback from GH UX preview opt-ins…)

[dirkf]

The design whereby issues are listed in a single page is fundamentally useless for an issue with more than a few tens of posts. It should be possible to show an issue with a large number of posts in a multi-page scheme where it isn't necessary to expand elided posts.

[willpower232]

"this editor" refers to the feature preview, I was trying to reference a chunk of code in a new issue in a private repo whilst this feature preview was enabled for me and the big textbox was empty

[MichaelChirico]

I'm also experiencing this on a public repo -- "Reference in new issue" flow is totally broken.

Previously, "Reference in new issue" would pre-populate some fields, especially copying over a perma-link to the highlighted code. That was the core appeal of that feature, otherwise I would just "copy permalink" and click the "New issue" button myself.

[MichaelChirico]

cc @akenneth in case the above got lost in the noise, this flow is still totally broken. Thanks for your efforts & triaging!

[MichaelChirico]

Thanks @MasterInQuestion, glad it's fixed!

[ichard26]

First all, I want to say congratulations on the new features! I haven't had the time to play around with them as the preview has just rolled out for my repositories, but they do seem useful on a first glance. Sub-issues and issue categories are of course totally doable with crosslinking and labels, but giving them dedicated space in the UI is nicer. I'll follow up if I have further feedback once I've played around the new features.

Anyway, I'm sure I missed the relevant discussions on the old (and unwieldy) thread, but I want to bring up two issues (🥁) I have:

The sticky issue header no longer states the creation date or the number of comments

New:

Before:

While I appreciate that some people probably don't need this information, I find it invaluable having these two pieces of information always available to me. When I'm sorting through tens of issues at once, it can be easy to lose track of what exact issue I'm on. For example, if I'm looking at an older and more heavily commented issue, I'll probably prioritize fixing this issue over a newer issue with less activity. Of course, I can still find this information from other places, but I have to click or scroll away, when with the old UI, it was just right there!

Is it possible to readd this information to the header? If not (maybe it's used by the new features?), could we at least add a count of comments somewhere on the issue view?

Labels are overly aggressively truncated in the timeline

This seems to be a trend with all of the recent UI refreshes. I get that making an UI less busy is nice and all, but there is more than enough room to display the full type: feature request label without being truncated.

Shown issue: pypa/pip#13165

[stosic]

Are there any additional pieces of information you believe should be included in the timeline or sticky header to make the interface more useful?

[amotl]

Hi. If I am hitting the right thread here ¹, let me add that the repository name might be dearly missing!?

Currently, on the new issue detail view that is delivered as a semi-overlay, there is no way to know if I will be commenting on an issue located in a private repository or not, which is pretty important to know.

Please fix!

Footnotes

1. Anyway, I'm sure I missed the relevant discussions on the old (and unwieldy) thread [...]

   ^^ This. ;] ↩

[rileybroughten]

@amotl we are working on adding this! Will provide an update when this change is out but should be early next week 👍

[amotl]

Thank you very much for fixing so quickly.

[janbrasna]

One piece of a11y feedback I'd love to see sorted somehow rather soon(ish), as I'm not currently aware of a way to opt-out of the UI (as that's managed on repo owner side, or org/enterprise side?) is this aggressive flickering loading the numbers and search highlights:

Screen.Recording.2025-01-14.at.22.38.10.mov

(Safari 18, macOS 15)

For my health condition this is only extremely uncomfortable, but for some others this flicker can be actually even dangerous.

Could this please only display once loaded fully, and not "fly in" from random directions? (I'd honestly prefer the static values as the classic experience or PR view has upon loading in the first place.)

[ohiosveryown]

Accessibility Is definitely an area we value heavily, so I really appreciate your feedback here. I'll file this and relay it to the team.

[janbrasna]

Thanks! I inspected the recording frame by frame and noticed: the numbers fly in from above, or move up and down; their labels move up and down; also the pills changing size and position, and the labels moving from their default positions to accommodate for longer number values after they are loaded; also while numbers invisible the filter dropdown labels next to it move left and right. That's a lot of movement!

[janbrasna]

I'm not entirely sure if that is also part of the new timeline experience, but it landed with it for me so it seems relevant:

Viewing edit history for individual comments has some changes that make it somewhat harder to understand what's added, what's changed, what's removed in the text… I was struggling with the "diff" color-coding there, will try to collect some samples over time to demonstrate the tiny things… However for now the bigger issue is the actual diff logic seems to have changed too, resulting in unreadable outputs like this:

[akenneth]

Thanks for the feedback @janbrasna! We are aware of this issue and I’ve logged your feedback against it.

[labudis]

We just shipped a fix for this @janbrasna - let me know what you think.

[Timmmy-nlb]

Hello,
we, companies, still need the required option in the issue forms to be able to enforce reasonable processes.
This only works in public repos and not in private or internal repos.

And "we" are many and do not need to be moulded:
https://github.com/orgs/community/discussions/148495
https://github.com/orgs/community/discussions/63402#discussioncomment-6968642
https://github.com/orgs/community/discussions/51500
https://github.com/orgs/community/discussions/4264#discussioncomment-1262667
https://github.com/orgs/community/discussions/63470
https://github.com/orgs/community/discussions/4349
https://github.com/orgs/community/discussions/4378
https://github.com/orgs/community/discussions/43859
[...]

[alondahari]

Hi @Timmmy-nlb, thank you for your feedback. I hear you (plural) and feel your frustration over this issue. I logged your feedback on our existing issue and will clarify what's our next steps here. 🙏🏼

[Timmmy-nlb]

THANK YOU - It works now!!!

[jfrost-mo]

Issues list flashes after loading

When loading the issue list or changing pages the list of issues flashes momentarily shortly after loading. See the following video:

output.mp4

I'm using a vertical 2560x1440 display with Firefox 134.0.1 on Windows 11.

[jfrost-mo]

Another minor issue that this video shows is the page title changes many times on a page load going through:

• Repo Issues
• GitHub - Where software is built
• Issues - Organisation/Repo

With the last being the one it settles on, and the useful one.

[dirkf]

These are just side-effects of the client-side JS lazy-loading implementation which is always going to be flaky in the real world (say, not in the Gbit LAN many-core client dev/test environment). This is a critical piece of site functionality and enhancements should build on the existing functionality instead of replacing it.

[alondahari]

@jfrost-mo This should now be fixed, could you verify? thanks again for bringing this to our attention! ❤️

[jfrost-mo]

The flashing is fixed, thanks!

The upon initial loading of the Issues list, the page title just goes through "GitHub - Where software is built" before settling on "Issues - Organisation/MyRepo", and only then if you do a hard reload (Ctrl-F5). However when changing page on the issue list the page title however now settles on "Repo Issues", after going through "Issues - Organisation/MyRepo". See the below video demonstrating this:

output.mp4

[alondahari]

@jfrost-mo Thanks for the report, I added it to our backlog and we'll take a look at that 💯

[dirkf]

The 'close-as-duplicate' function is the only real positive of the rework for me. Its problem is that you have to guess which issue is the non-duplicate master issue. The potential duplicate-of list should prefer or identify issues where the issue has already had issues closed as duplicate-of it. And it should be re-implemented so as not to require JS (and then it would be fine just to type in the issue number).

[jfrost-mo]

Issue title box is tiny when composing new issue

The title box when composing a new issue is very small. This makes it hard to type issue titles of more than a few words. This runs counter to encouraging people to give descriptive issue titles.

[jfrost-mo]

Testing in Firefox after you asked it appeared to be fixed:

However when I went to edge to test there, and it was still small:

And going back to Firefox after a Ctrl-F5 it is small again:

[jfrost-mo]

I'm running Firefox 134.0.2 (64-bit) and Microsoft Edge for Business Version 132.0.2957.115 (Official build) (64-bit) on Windows 11.

	Windows versions
Edition	Windows 11 Enterprise
Version	23H2
Installed on	12/‎12/‎2024
OS build	22631.4751
Experience	Windows Feature Experience Pack 1000.22700.1055.0

My CPU/GPU is an 11th Gen Intel(R) Core(TM) i5-1145G7

[jfrost-mo]

Relevent HTML:

Compared with a working bar editing an existing image, this one is missing the InlineAutocomplete-module__fullWidth--X6eXo class.

[labudis]

thank you for the additional info @jfrost-mo - passed this on to the team investigating this.

[jfrost-mo]

This appears to be fixed today. I've tested in Firefox and Edge, after various page refreshes, and with and without a template.

[mcanouil]

Could sub-issues inherit from the parent labels by default?

[labudis]

@mcanouil thanks for the suggestion! Would you mind sharing an example of how you would use this?

[mcanouil]

For example, in some repositories my client has a workflow based on labels: priority, difficulty, type (bug, enhancement, etc.), component (codebase, analysis, etc.).
It's used to assign to GitHub projects amongst other things.
Each time a sub-issue is created, they need to go to each of them to add the exact same labels, some times with slight change for priority/difficulty.

To me, it makes sense to have an inheriting behaviour by default rather than having issues with no labels, milestones, projects even though they are created from one with.

Note: the issue was also there with the "item-issue" before the preview, so not really a new problem.

[ohiosveryown]

We've discussed inheriting meta data as we were building the feature, and it's something that's come up before. You mentioned labels, milestones, etc. Is that what you would expect? Or just solely labels?

[mcanouil]

Mostly labels.
Milestones make also sense to me in the sense that if you added the parent to a milestone, it likely means your sub-issues are also in that milestone, but I don't have strong expectations on milestones.

To summarise in a concise way:

Meta	Inherits
Labels	Yes
Type	Maybe
Milestones	Yes/Maybe
Project	Maybe
Assignees	No

[eishiya]

Looking forward to trying out the advanced search! I very rarely need it, but when I do, not having it hurt.

I don't like how accessing Most Reactions, Least Commented, Least Recently Updated, etc all take extra clicks now. Sure, the menu looks tidier now, but it's made browsing issues slower, without any new functionality that warrants the more complex interactions. The original menu was not large or overwhelming, it doesn't need to be shrunk. If it's being shrunk for phone users: cool, show that to phone users, not to people with proper screens :] I think even phone screens tend to be high-res enough now to fit the old menu quite comfortably, though.

(And it's inconsistent with the PRs list. Presumably that'd be fixed eventually, but really I'd rather see the old PR-style menu kept, as it's more convenient, with everything available with one click in the menu.)

(Edit: Whoops realised this is a Discussions thing probably not connected to the Issues rework, shows how often I use Discussions xP)
I think the background colour for replies on issues is too high-contrast, at least in the Dark Dimmed theme I'm using. Replies are important and easy to miss if not highlighted, but they don't need to grab my eyeballs out of my skull to be noticed xP Played around with just disabling that colour (so the default background colour shows through) and I think that looks plenty good, and if you want to highlight replies more than that, I think perhaps making the indent-line next to them higher contrast would be the way to go - it wouldn't hurt the contrast or readability like changing the background colour does, while still calling attention to replies.

I also noticed while editing this that sometimes the post input box collapses for a frame before reappearing sometimes. That never happened before.

[labudis]

Thank you for your feedback @eishiya! I'm glad you are enjoying the new advanced search!

We take your comments on board regarding the layout changes. There is always a tight balance between keeping things tidy and introducing additional steps to accessing functionality.

[eishiya]

Another usability gripe from me: When opening a link to a PR/commit from an issue via the "{user} closed this [...] in {PR}" text, it opens in a new tab, whereas before it opened in the same tab. Other links in posts in issues also open in the same tab. For consistency, and because it's much easier to force a same-tab link open in a new tab than to force a new-tab link to open in the same tab in most browsers, I think these and similar links should open in the same tab.

[PLTytus]

Looks like some issues are hidden with default filters on this preview.

[alondahari]

@PLTytus thanks for reporting! should be fixed now ❤️

[PLTytus]

It is good now. Thanks for quick fix.

[legobeat]

The search function no longer works when client-side JavaScript is disabled in the new experience. Various aspects of the filtering (which work in the old experience) also break.

[kittydoor]

Already being a purely proprietary platform, GitHub always has a very sensitive place in my list of tools, and every action taken is something I use to re-evaluate for what purposes I will use GitHub over other platforms like Sourcehut, Codeberg, or self hosting forgejo.

I'm sure I am far from the only programmer who is constantly making these re-evaluations.

The website not working without JS enabled for the core functionality is one of those things that is hugely detrimental to my ability to ask others to collaborate with me on GitHub.

I know in the corporate world we don't talk about this a lot, but there is countless contributors outside of that who are taking their personal time to, out of interest and principle, build and share software. Functionality without JS enabled has a lot of importance for that.

[legobeat]

@legobeat unfortunately, there are no plans to support a no-JS experience for Issues moving forward. Can I ask why it is important to you that the system works with JavaScript disabled?

@labudis Do you think there is any chance this will be resolved now that the feedback period is closed, or does this stand, meaning that the accessibility points laid out above are not at all of concern for GitHub? To me this looks like a significant shift from what we could read in the past about GitHub's supposed commitment to accessibility?

[labudis]

Hi @legobeat,

Thank you for sharing your concerns about accessibility with us—it’s something we take very seriously. We are continuously working to improve, and in the past three months alone, we’ve resolved 29 accessibility issues within the New Issues experience.

We truly believe it’s possible to provide an accessible experience, even within a system that relies on JavaScript. That said, we understand that individual needs can vary, and we want to ensure your voice is heard.

If there’s a specific accessibility issue that’s impacting you personally, please don’t hesitate to raise a support ticket. This will allow our team to investigate further and work toward a resolution that supports your needs.

Thank you again for bringing this up, and we’re here to help in any way we can.

[CyrilleB79]

@labudis you write that you have fixed 29 accessibility issues.

Where can I see accessibility related issues (opened and resolved)?

More generally, now that this feedback thread is closed, what is the best way to report other accessibility issues? (or other ones) What about the issues that have been reported in this thread?

[labudis]

@CyrilleB79 Thank you for your question. Unfortunately, we don't have a public list of all bug fixes. However, the best way to report any accessibility issues you are impacted by would be by raising a support ticket.

[CyrilleB79]

Hi,
Another accessibility issue, tested with NVDA in focus mode.
When you up/down arrow in the issue list on this page and you reach the issue related to ui.browseableMessage, you can hear HTML tags (<code> and </code>); you should not hear them.

[owenniblock]

@CyrilleB79 I see what this is, it looks like the aria-label we generate takes the literal string from the title (including the <code> tags) - I'll log a bug here and get the accessibility folks to prioritise it for us. Thanks for the feedback!

There's an interesting additional consideration here - the screenreader won't tell you if it's a code block or not. I guess we could either accept this, or use to original text with backticks instead of the HTML tags: `ui. browseableMessage` - do you have a preference?

[owenniblock]

As a workaround, you could remove the backtick characters (`) from the title for now.

[owenniblock]

@CyrilleB79 just wondered if you had a few minutes to help us decide whether to filter out the <code> entirely or whether to display it with backtick characters?

[CyrilleB79]

@owenniblock sorry for not answering earlier.
IMO, totally skipping code block formatting in the aria label is acceptable, i.e. do not even keep backticks. In any case, the screen reader won't report formatting in focus mode; for this I need to switch to browse mode and use the suitable screen reader options.

[owenniblock]

Thanks @CyrilleB79 - I'll record this on the issue I've logged on our end.

[simar7]

If new feature preview is enabled, I simply cannot create issues if issue templates are selected. Happy to dive into more details if someone requests - otherwise this completely breaks everything with regards to issue creation in our organization.

[simar7]

@alexus37 the problem as I mentioned earlier is that we can no longer create issues by visiting https://github.com/aquasecurity/trivy/issues/new/ It simply redirects us to https://github.com/aquasecurity/trivy/issues/new/choose which is wrong.

Creating an issue from a discussion was just a workaround - I don't expect it to be the way to create new issues going forwards. If it is, it's highly clunky and requires additional work.

[simar7]

It's already been reported by @Haarolean here https://github.com/orgs/community/discussions/148713#discussioncomment-12576663 - disabling feature preview isn't an option anymore (at least for me) so we're simply stuck as we cannot create issues.

[alexus37]

@simar7 Thanks for the additional info. I just checked the ISSUE_TEMPLATE/config.yml in your report and you have disabled blank issues therefore we redirect you to the choose page. If you want to allow blank issues you can flip that flag to true.

[simar7]

Yes but as a maintainer I should be able to create blank issues as I was before. To me this is a breaking change as previously I was able to create issue and not anymore.

[labudis]

@simar7, I've responded to @Haarolean in a separate thread but I think you are both experiencing the same issue.

The ability to create blank issues via the /new path when the blank_issues_enabled setting is off was a system defect. This allowed contributors to bypass the Issue Template configuration and create blank issues, which led to complaints about poor-quality issues. To address this, we have fixed the defect and now redirect users to the template picker instead.

That said, I understand the need for maintainers to create blank issues while still enforcing templates for contributors. I’ve logged your suggestion as a feature request, and our team will be considering a solution for this.

[Haarolean]

I recently noticed that unlike in the old experience, with the new one I can not create a template-less issue.
I have blank_issues_enabled: false set so users don't open up random issues, but I need this thing for maintainers.
I used to do this via URL: https://github.com/kafbat/kafka-ui/issues/new, but in the new experience it automatically gets redirected to https://github.com/kafbat/kafka-ui/issues/new/choose instead. Would be nice to see this reverted or we need another way for org members to ignore this rule.

[Haarolean]

Amazing, can't turn off the preview now and can't create an issue without filling a ton of fields. Well done github!

[labudis]

Hi @Haarolean, thanks for your feedback! I work on the Issues team alongside @alexus37.

The ability to create blank issues via the /new path when the blank_issues_enabled setting is off was a system defect. This allowed contributors to bypass the Issue Template configuration and create blank issues, which led to complaints about poor-quality issues. To address this, we have fixed the defect and now redirect users to the template picker instead.

That said, I understand the need for maintainers to create blank issues while still enforcing templates for contributors. I’ve logged your suggestion as a feature request, and our team will be considering a solution for this.

[Haarolean]

@labudis @alexus37 was being able to create an issue via gh cli also a system defect?

$  gh issue create

Creating issue in kafbat/kafka-ui

? Title (required) test
? Body <Received>
? What's next? Continue in browser
Opening https://github.com/kafbat/kafka-ui/issues/new in your browser.

I get redirected to
https://github.com/kafbat/kafka-ui/issues/new?body=test+body%0A&title=test
which gets redirected to
https://github.com/kafbat/kafka-ui/issues/new/choose
losing all my data I've put in my cli.

$  gh --version
gh version 2.72.0 (2025-04-30)
https://github.com/cli/cli/releases/tag/v2.72.0

[simar7]

@labudis I don't think this was a "defect" per se as @Haarolean pointed out the ability to create blank issues via the CLI is now also broken. I understand the motivation behind you closing the door on blank issues for now given you cite poor quality issues but ultimately the responsibility of quality of the issue should lie both the community and the maintainers.

Providing templates increases the quality of issues from the community / external contributors but a maintainer should have the free-will to decide if or not to be able to create issues that are freeform. In fact for us the reason we used this way was to open issues that we are already aware of and doesn't require us to start a discussion on first simply to then switch them into issues right away.

[simar7]

As a potential solution, could there be an option to enable blank issues just for maintainers of the project? That would be fairly straightforward to understand and be explicitly something maintainers can opt-in for, if they choose to enable such functionality.

[lucafaggianelli]

I'm using the "Create more" checkbox when creating new issues, it's a nice feature, though the new issue form is filled with the newly created issue so it's pretty annoying as I need to clean it up everytime

[alexus37]

👋 Thank you for reaching out and sharing your feedback! To help us address the issue, it would be very helpful to have the steps to reproduce the problem or a short recording. Would you mind sharing those with us?

[lucafaggianelli]

I reconstructed what happened:

1. Create a new issue checking the "Create more" checkbox
2. When creating the second issue I needed to create a new label
3. Click on Edit labels, this brings you to the manage labels page
4. go back to create your issue
5. all the following issues will contain the body and title of the second issue you created

Now checking the localStorage in the browser console I see the title and body of the issue stored there, so I closed the window and reopened it and the fields where cleared

[dacort]

Creating or deleting new issues with the preview feature doesn't update the issues count on the top navbar.

Repro steps:

• In a repo with this feature enabled, navigate to the <repo>/issues
• Click on "New Issue"
• Fill out the issue and click "Create Issue"
• When redirected to the issue, notice that the number shown next to "Issues" in the navbar has not incremented
• 
• Refresh the page
• Note that the issue count has incremented
• Delete the new issue
• Note that the issue count remains the same
• 

This happens whether or not "Create more" is selected.
Source repo: https://github.com/dacort/dotfiles

[kamil-gwozdz]

Thanks for reporting this. It's on our radar now and we'll report back once it's fixed.

[janbrasna]

BUG: After navigating to View Templates and then using back button, scrollbars are gone so it's hard to navigate the page:

https://bugzilla.mozilla.org/show_bug.cgi?id=1957346

As I've noticed when navigating on GitHub and trying to file a new issue, the scrollbars will be lost and you are no longer able to scroll the web page when navigating back after having clicked the GitHub new issue button and View Templates link. This can be reproduced with the following steps:

1. Open https://redirect.github.com/microsoft/playwright/issues/32577
2. Click the New Issue button so that a popup will appear and the scrollbars already removed
3. Click the View Templates link
4. Navigate back

After step 4 I expect the former page being shown with scrollbars but those are still gone. A reload makes them visible again. Note that clicking just a template doesn't produce this failure. It seems to only happen with the View Templates link.

FYI I've tried with several different pages and different issues and can only reproduce on that exact page linked in STR, so this may be related to some lazy loading or bfcache handling on that starting page, being different than e.g. starting from the issue list or another random issue on the project.

[boazreicher]

Thanks for reporting this @janbrasna . I can also reproduce this issue (using Arc, and the same repro steps that you posted).
I'll file an internal issue for the team.

[shoeper]

I do not like opening sub-issues in-page making use of another layer (as can be seen here). This deviates from standard browser behavior, is complex to use, and does not offer a benefit.

[CyrilleB79]

Neither do I.
As a blind user, I was quite surprised to have a sub-issue opened in the same page, but the title bar of the browser still labeled with the title of the main issue. That's a quite confusing UX (misleading title bar, escape turning back to the main issue) for no real benefit with respect to just opening the sub-issue in a new page/browser tab.

[owenniblock]

Logging an issue with in our external accessibility repo, will let you know if this gets worked on in future. Thanks for the feedback!

[0x0blu]

The update removed the ability to order issues/PRs within a milestone, which helps a lot with merge ordering and prioritization.

[yacine-harbi]

This is a terrible decision. Without ordering, issues and milestones lose their purpose. Enshittification at its finest.

[robennals]

Is there a way to out out of this new interface until it contains the basic functionality present in the previous one?

We used issue ordering in milestones as our primary way of prioritizing tasks. The new update has lost all our prioritiation, and the supposed replacement with sub-issues doesn't seem to be usable in it's current state.

We'll likely have to migrate our task management off of github, which is going to be a massive pain.

At the very least, give us the ability to automatically generate an issue with sub-issues, based on our pre-existing milestones with sorted issues in them.

[labudis]

I wanted to take a moment to express my sincere appreciation for all the feedback you've shared in this forum. Although the custom-ordering feature may not have high overall usage, it is clear that it has a passionate base of users who rely on it for their daily planning needs. Your insights have also highlighted some gaps and limitations in alternative solutions like sub-issues and Projects.

Now for the good news: I am excited to announce that my team and I are actively working on a plan to reintroduce custom ordering to Milestones. Please stay tuned for updates coming very soon!

Thank you for your continued support and valuable contributions.

[labudis]

Hi everyone, I'm excited to share that we've now rolled out the refreshed milestone issue ordering feature to all users. Please test it out and let us know if everything works as expected.

Below I have attached a little demo of how the feature looks:

Milestones.Custom.Issue.Ordering.Preview.mp4

Thanks again for your patience as we worked to restore this critical functionality for you all!

[mlcnp]

@labudis Thanks so much for restoring this super critical functionality for those of us who've relied on it with our teams. I've been using the feature and noticed that the reordering sometimes does not stick on reload. There doesn't seem to be a systematic way to reproduce the issue, but it has been a little frustrating to make reordering changes, only for them to be completely obliterated on browser refresh or URL reload.

What kind of information can I provide to help you debug this issue?

[amotl]

Hi. Thanks for improving GitHub issues. Is it possible that the feature had been turned on for everyone yesterday, and the ability to disable it is currently defunct? We tried to disable it per https://github.com/settings/admin, but it apparently does not work.

The reason why we want to disable it is because the repository name is missing on the new detail view that is delivered as a semi-overlay. We added a corresponding report per https://github.com/orgs/community/discussions/148713#discussioncomment-12726403.

Please help!

[rileybroughten]

@amotl responded on that other thread, but we are currently working on adding in the repository name and can expect to see that soon!

[Calinou]

I'm not sure what's the best place to report this, but I found a bug with the search syntax reporting a warning for syntax that is valid:

https://github.com/godotengine/godot/issues?q=is%3Aissue%20state%3Aopen%20created%3A2025-03

Specifying YYYY-MM or even YYYY is valid, and will return all issues created within that time frame (March 2025 in the above example). It also works on https://github.com/issues and https://github.com/pulls. No warning appears if using a YYYY-MM-DD syntax, but I want to see all issues created within a month with the simplest syntax possible.

[rileybroughten]

Thank you for reporting this! We are looking into it and will provide updates so an invalid warning does not appear 👍

[rileybroughten]

@Calinou this has been fixed! Let us know if you encounter this again 👍

[Calinou]

Works great, thanks!

[andrzejressel]

I have issues creates by bot pinned to top. When hovering over name the box is shown:

This box is not shown when hovering over "normal" issues:

The box contain invalid information - the picture is wrong and link on user's name is "https://github.com/renovate" instead of "https://github.com/apps/renovate"

[swrobel]

It would be amazing if you just implemented the status-subscription feature from Refined Github as the default UI in the new issues view:

[Sainan]

I'm guessing this redesign just yeeted task lists. I no longer see the "x/y tasks" on issues. Documentation for it also doesn't say anything: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/about-task-lists

[Sainan]

Ah, they're being retired. I highly urge you to reconsider. I don't see how counting occurrences of [x] is any extra work for you, plus it's easily cached. Tasklists are often a dozen items, sometimes considerably more. There is no way you expect people to go through the steps of creating a new issue and linking it to another issue dozens of times? It's also needless clutter for the main issue list because sub-issues still appear there.

[Haarolean]

I agree, that's insane. It's just a bunch of markdown.

[stevensecreti]

Looking for support for an Issue type, when creating a custom field within a Github Project

The idea is to create a custom field to track dependencies between issues. For example, Issue B has a dependency on Issue A, so Issue B can not be implemented until Issue A is closed.

Is this something that is on the roadmap? I've seen this idea previously in a variety of other issues and threads, but they all seem to be closed with the latest release of issue types / sub-issues.

Reference Issue

[labudis]

@stevensecreti have you seen this recent announcement for Dependencies? This feature was designed specifically for the use case you are refering to. Let me know if this fits the bill.