Differential currently has a unique "bucketing" query UI, where the "Active Revisions" filter is hard-coded to split revisions into multiple buckets ("Blocking Others", "Action Required", "Waiting on Others").
It seems legitimately desirable to show this kind of composite dashboard rather than splitting these buckets across multiple pages. For normal users, the number of items in each bucket is small and these buckets approximately capture the most relevant information in the majority of use cases. In Audit, where we don't have buckets, this is particularly apparent: "Needs Audit" and "Problem Commits" have about equal strength in terms of needing attention, but them being on separate tabs feels junky.
However, there are also a number of disadvantages. Some are particular to the implementation of buckets in Differential:
- The Differential bucketing rules are inaccurate or confusing in some cases. In other cases, they're accurate but complex and it's sometimes unclear to users why a revision is in a particular bucket (some discussion in T1279, and elsewhere).
- Some users just want different buckets (T4144, T4055, T2511) -- both different from the defaults, and different from one another.
Some are common to any bucketing:
- Bucketing is entirely application-side so there's no way to paginate buckets, and pagination isn't technically feasible with the current approach. Differential just executes the query with a huge page size. This is reasonable because few users have thousands of revisions, but it is more possible to have thousands of audits or thousands of tasks.
- Bucketing is currently hard-coded and won't generalize cleanly to ApplicationSearch-based Conduit methods.
Driving this purely from the technical constraints we probably end up with some kind of "dashboard queries" which are composed of other queries. Maybe these are even real dashboards, although this feels needlessly powerful and probably confusing (there is no reason for users to turn `/differential/` into a list of the latest image macros and calendar events, and letting them do that will necessarily make it harder for them to do more reasonable things).
This feels complex, but tractable. I think the biggest issue is that it means each bucket needs to be individually expressible as a query. This is fine for Audit, but:
- There's no way to express any of the Differential buckets with a query right now.
- There's definitely no way to express all the extra crazy junk users want with a query.
- There's absolutely no way to express things in T9263 with a query; the naive fix for it is this:
{F786899}
Many of these bucketing rules can't be executed in the database, or can only be partially executed in the database.
So this probably reduces to:
- Figure out how to reasonably provide these high-complexity filtering/querying rules.
- Build meta-queries out of queries.
This is only slightly less complex than the original issue. This also doesn't specifically provision for making bucketing rules more transparent, although maybe that's OK since the bucketing confusion may mostly be a result of bucketing errors.