"; v@

@adlai Did you ask ChatGPT to "use lots of big words and make my paragraphs as verbose and long as possible" when you wrote this comment?

Richard Reukema wrote,

[a good workaround]

If I may explicate, for the benefit of folks [like me!] less familiar with the full taxonomy of project management features offered both by and outside of github:

I would use tags, as this is a good use case for that feature - it removes convention from string fields

One of the most pernicious unintended evils that arises in long-lived feature-crept applications, especially when multiple individuals collaborate, is the undocumented invariant. One simple example of undocumented invariants could be the C-style int return code, where zero usually means that desirable side-effects occurred, and nobody has any idea whether any side-effects hinted by nonzero return codes were desirable without reading amounts of documentation not determinable in advance from the error code alone.

How is this relevant to the workaround in question?

The following intermediate navigation list within the documentation for Issues is required reading before marking my comment Off-topic: different fields and custom field types

I'll cut myself short, to avoid wasting too much of your time; most of the useful string descriptions for Issues are actually elements from much smaller spaces, than the complete space of arbitrarily editable strings. Tags [aka Issue Types] are a way of defining, preferably with agreement of project maintainers, a preferably short list of significant words, and then the arbitrarily eloquent opinions can go in a separate field that doesn't cause unexpected failures in sorting code that must make decisions based on the content of these descriptions.

Hmm... That would be a little tricky as they represent the days of the week; however, I realize now that I can use a "Field type" of "Date" and achieve the same @current view I had by filtering for @today, so I believe I can work around it. I'll follow up if I run into any other issues. Thanks for looking into this!

Awesome, thanks!

Actually, is there any option when grouping by a "Date" field in the "Table Layout", to include the day in the header summary? Currently it displays just the month abbreviation, day of month, and year (e.g. Feb 28, 2025)... At least with my locale (US East Coast).

@evi-liu I've now found that when I have a "Board" Layout, that is filtered for <date-field>:@today, when adding an item to one of the columns it does not automatically create the item with the <date-field> updated to @today. This means that I get a message that "The new item is hidden by this view's filters." and I need to open the item and manually update the value of the <date-field>.

If I "Group by" the <date-field> it is automatically added, but this creates unnecessary clutter in the view as all items fall in the same group (as they are filtered to only come from that group).

Also, if I "Slice by" the <date-field> and select it from the side menu it also works to be automatically added, but similar to above this seems like unnecessary clutter.

Is this a new bug as part of the trial or something that has long existed when filtering for @today?

Thanks for reporting! We did recently change the export behavior to only export the rows that have loaded into the project. If you've given the project time to load in all the items and they're not all exporting, that's indeed a bug. I've logged it for our team to take a look!

Thanks @evi-liu , I figured that was the case, though it's not loading even after waiting ~30 seconds. Even some loading feedback so we know that it hasnt actually finished loading would be helpful.

You may have to scroll to make sure all of the items are loaded.

Could you let me know if fully scrolling down on the page allows you to export all of your desired items?

Thanks for reporting! I have it logged as a bug on our team backlog now.

I've encountered a similar issue with sorting strings. I have a "Release" field containing SemVer version numbers, and previously, they sorted correctly like this:

1.1.0
1.2.0
1.10.0

However, now they sort like this:

1.1.0
1.10.0
1.2.0

I understand this behavior for a text field, but I really appreciated the convenience of having version numbers treated as actual versions. Now, I have to pad with zeros to maintain order, which feels a bit tedious.

Please include details

Thanks for logging this feature request! We will prioritize this alongside our other feature requests.

I believe it is related to this item, but I noticed that Issues can be blocked, it would be nice if this function was also more accessible in the panels, including in the filter. It could avoid the need to create situations, columns or tags for this!

Hi,

Thank you for the prompt reply. Here's the overall view that shows only the first match rendered (rest are not showing up)

Thanks

Hi @NISH1001 , thanks for the additional information and your patience as we investigate this one. Since you're filtering on an iteration field, a great workaround would be to filter relative to the current week using the @current keyword. In your case, it looks like you want something like: week:@current-5..@current+4. That filters the week iteration field to return values within the range of 5 iterations before the current week through 4 iterations after the current week.

Please give that a shot and let us know if that works for you. Heck, you might even like it better since you won't have to keep adjusting your filters each week. Of course, we'll get this fixed regardless. Thanks again for bringing it to our attention!

@jayspadie Thanks for the @current filter. That feels more tangible. Looking forward for the week-based filter because the original view I had also helps in getting overall timeline-view for the entire PI we planned ahead.
Appreciate your reply.

I'm also facing this issue, in my case, this filter allows me to have iterations from "Q1 - Iteration 1" to "Q1 - Iteration 6" with just "iteration: Q1 - Iteration" filter. I'm only interested to display iterations from the current quarter not next quarter. Using current as filter will show iterations from next quarter at some point.

These bugs should now be fixed! ✨ Thank you for your patience, and let us know if you're still encountering it.

Can you try lowercasing status?

So like this: -status:Done

That should fix it, I think, but let me know.

Filtering is definitely not a great user experience. I used to be able to filter by selecting the three dots to the right of the column title and make my selection(s). This is not functioning as it did previously and is frustrating. Now, I have to know exactly what the name of the filter is an apply it in the search bar. Seems that the filtering functionality has regressed significantly.
Additionally, when I clear the search query, the dropdown menu that displays continuously displays and there isn't an easy way to remove it from view.

Hi there, this seems to be a bug unrelated to this public preview, but affecting many project boards. We are actively working to resolve it, and sorry for the inconvenience!

@callaway-james-delano thanks for reporting and apologies for the disruption. As @evi-liu noted, it was an unrelated change behind a feature flag that seemed to affect Windows machines. We've disabled that flag now. Please let us know if you continue to have any issues with drag-n-drop. Thanks again.

It's back! Thank you!!

Thanks for logging this feature request! We will prioritize this alongside our other feature requests.

This is a step backwards for UX for me. The reasoning that it benefits projects with a large amount of issues just isn't compelling to me. Perhaps there is a way to toggle this functionality if required?

@BoltTouring thank you for the feedback. While this update is still in preview you may opt out of it from the "Danger zone" section of the main settings page of a project as detailed here.

However, we are unlikely to support the old UX beyond the preview period because it could not scale to larger use cases, and we do not have the resources to maintain two architectures. As @evi-liu mentioned, our goal during this preview period is to close the gap to the old experience wherever possible, so we appreciate your patience as we work through incoming feedback and associated fixes.

And pretty often the whole view just goes empty/blank/black and you need to do a page refresh to see them again 😢

@Alex-ley-scrub sorry to hear this. Are you able to record a video or describe in more detail the circumstances that lead to this bug? If you would prefer not to post that publicly, you can send it to me via email (my GitHub username at github.com)

I am no longer able to load my most current iterations as it seems to load forever past the first 100 iterations

@tamidodo could you please describe how, if at all, the view you are using is filtered? Assuming that you're primarily interested in your most recent iterations, then I think it may help to adjust your filters. For example, if you are interested in the three most recent iterations, applying a filter like iteration:>=@current-3 will likely fix your loading issue. If you are indeed auditing all your iterations, then any further details as to how the view is organized (e.g. is there any grouping or sorting applied to the view? is it a table or a board view?) will help us investigate further.

Hey @evi-liu and @lerebear,

we're currently working with a project that includes 11,391 items, including parent issues. Unfortunately, we're experiencing significant performance issues:

• Loading items takes a very long time and sometimes gets stuck entirely
• Bulk editing items slows things down even more
• Performance drops drastically when multiple users (e.g. 2 or more) are working in the project simultaneously
• In some cases, the page turns completely black and becomes unresponsive, forcing us to reload and start over
• We're about to onboard even more team members, which makes this issue even more critical.

Since you mentioned that performance is a top priority, is there anything you would like to investigate on your end? Let us know if we can provide any additional info.

Thanks!

@danny-mcg could you please send me the URL of your project and, if possible, a video of a typical session that exhibits the above issues? My email address is my GitHub handle at github.com. We'll use that information to review your project configuration and inspect your network traffic patterns to see if we can identify the source of the problem.

Similarly to Charles (comment above), We have view with less than 100 items in a View and the lag is insane.
I don't see the point of increased limit if you make all projects from all customers barely usable...
Any ETA on an update to get back to previous performances?

Thanks

Still annoying and not glorious as before @jayspadie, but thank you.

The changes disrupt my workflow and preferences so much.
I think opting out of the "increased project item" update works for me.
Maybe in the future I'll join back - who knows? 🤷🏽‍♀️
But for now I've opted out, and my project board is back to the way I love it ❤️

This part is scary though. I do hope this doesn't happen.

Additionally, please note that the increased item limit will be fully rolled out in the coming weeks without an opt-out option. We’re actively addressing reported bugs, so keep your feedback coming!

No sure what the things you've written mean @adlai
Allow GitHub peeps to see comments that matter 🙏🏽

Thanks for your feedback, @jmssltd. We're investigating all reports of filtering issues and finding a few edge cases here and there. We're not aware of any general issues that would prevent some columns to fail to show. If there are many board columns, we do paginate additional columns while scrolling to the right. Is this what you're seeing? Is the column pagination not working consistently for you?

If there are any particular filters that don't seem to be getting applied as expected, it would be really helpful if you could provide the filter string here to help us investigate. Screenshots of any filters and items (redacted as you see fit) are always helpful and appreciated. Thanks again!

Thanks for reporting! I've passed it along to the team, and we are looking to fix it.

Hm, I'm not able to reproduce on my end. Could you give me an example of what your orderings were before and what they are now?

Hey @evi-liu , here's an example of what @akselinurmio is referring to. It's known behavior at this time, but understandably not necessarily desired.

• Filtering is case insensitive.
  • Here, I am filtering on "hello", matching regardless of casing
• Slice and group values (and ordering) from the project items are case sensitive.
  • Here, we get 3 different groups/slices based on casing, with uppercase "Hello" ordered first.

Facing the same issue here. I would have expected a list of all such changes to be announced before rolling them out.

We are looking into this to ensure the sorting remains case insensitive. Apologies for the disruption, and thanks for the patience!

I hear you, and apologies for the distraction. The green preview pill follows a standard GitHub pattern to highlight new features. We’re aiming to move this feature out of preview soon, so it won’t be around for long. Appreciate the feedback!

Thank you for the feedback on this! Our team is currently working to improve partial string searching. I'll circle back on this thread once we've improved this experience.

This issue is not about partial string search, but about searching in the body of issues.

I see. This would be net new functionality for GitHub projects, so do you mind opening a feature request for this here?

Ah interesting. So essentially, the manual order is some interleaving of all items in all groups, which would become obvious if you removed the grouping. But that interleaving is invisible to the user when using grouping, thus resulting in unexpected behavior. Because of the way the UI is represented, the user would probably expected the manual order to only apply relative to items within the same group.

@aardappel Yes, each project item has a manual order/position value that serves as the order tie-breaker anywhere that multiple items are rendered. That applies within a group or ungrouped, sorted or unsorted, etc. A newly added project item begins at the bottom of all other items, but its position can be updated via drag-n-drop relative to other items. That works even when grouped (with or without additional sorting), with the exception of this particular scenario/bug when the view is also sorted by the same grouped field.

So, for example, if one drags item X above item P in a group, then X will be above P in all views (grouped or not) if the order is not otherwise determined by the Sort by field(s) of that view.

@adlai, thanks for your feedback. The manual positioning I described is an implementation detail that isn't intended to be visible in the UX. I only mention it here as part of a complete response from investigating the bug that @aardappel reported. This internal manual position simply provides a relative ordering of project items based on the user explicitly specifying a position via drag-n-drop in various views including tables and boards, and the actual value could change over time as needed to maintain that relative position after multiple item moves and inserts.

I certainly wouldn't consider our custom fields for defining item attributes that can subsequently be used to configure grouping, sorting, and slicing as a jury-rigged solution for ordering, but if you have a particular scenario where you feel like our support for automatic sorting and manual ordering is lacking, then we'd like to know more details.

Of course, this conversation is diverging a bit from the scope of our Increased Project Item Limits Preview since the support for sorting/ordering hasn't changed with this update for increased limits, so I would recommend submitting a feature request as a new Projects and Issues discussion if you would care to do so. Thanks again!

Thank you for the feedback! As this community discussion is dedicated to the increased project limits public preview, do you mind opening a feature request for this here?

Thank you for the feedback @trinode-work. Could you please confirm what view type you are using and how exactly you are moving items programatically? My hunch is that you are using the board view and that you move items via the built-in workflows (e.g. when an item is closed, set it's status to "Done"), but I wanted to confirm.

@trinode-work, I should also add that the updated filter may provide you with a serviceable workaround for your problem. For instance, adding state:closed updated:>@today-1w will filter your view down to things that were closed in the last week, which will likely be a much smaller set of items that does not require as much scrolling.

@chrisjacobs91 thanks for your report and sorry to hear that things are acting strange. The short answer is that no, there should not be a practical limit on the number of items you can see is your example view. If you add a new item for "April Week 3", then it should remain visible in that group.

I've not yet been able to repro this issue myself, but I can get it to incorrectly show a warning that the newly added item won't be visible because of the filtering (image below). That warning is generated on the client, but it's apparently failing to correctly determine that the new item in that group will match the iteration filter week:>=@previous-1.

To help us troubleshoot:

• Are you seeing that warning that the item will be hidden?
• Can you confirm that the item is actually hidden?
• Does the item show up if you click to refresh the page on that view?
• Finally, can you please check the project settings for that "Week" iteration field, and let us know if there are duplicate iterations named "April Week 3" (perhaps from last year)?
  • Iterations with the same name are known to cause some problems with filtering/slicing/grouping.

We typically load the first X project items for each group, then load additional items as the user scrolls down for more. We've had a few cases in the past where collapsed or sparsely populated groups created a situation where we were not triggering the additional loading of items, but it's my understanding that we have fixed those edge cases. I thought perhaps that this was another new example, where the additional item exceeds the first page of items but we weren't refreshing the view correctly to account for it, but I've not yet been able to repro it. Thanks for any additional information you can provide to help us determine the cause.