feat(search): Add "recommended" issue sort#111043
Draft
Conversation
Add a new experimental sort option (?sort=recommended) that combines four normalized [0,1] signals additively to rank issues: - Activity (0.30): recency with 24hr halflife + 6hr-vs-7d spike ratio - Severity (0.25): max log level (fatal→error→warning→info→debug) - Momentum (0.25): recent-vs-prior 6hr window volume comparison - User impact (0.20): log-scaled unique user count Unlike the existing trends sort which uses multiplicative combination (where any near-zero factor kills the score), this uses additive combination so signals contribute independently. Weights are tunable via the options system without redeployment. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
github-actions
bot
added
the
Scope: Backend
mrduncan
changed the title
Backend events often lack associated users, so issues with high event counts but no user data get downranked. Add a log-scaled event volume signal (ln(count+1)/ln(10001)) so high-volume issues without user attribution still rank appropriately. Redistribute weights across all five signals: activity (0.25), severity (0.20), momentum (0.20), user_impact (0.15), event_volume (0.20). Also fix module-level options.get() calls that failed before cache initialization by evaluating aggregation expressions lazily. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Remove the momentum signal — activity already captures recency and volume spikes, making momentum redundant. Shorten the spike baseline from 7d to 3d so the ratio is more responsive to recent trends. Redistribute weights across four signals: activity (0.30), severity (0.25), user_impact (0.20), event_volume (0.25). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The combined activity signal mixed two distinct concepts — how recently an issue was seen and whether it's currently spiking. Splitting them into independent signals makes each independently tunable via options. Weights: recency (0.20), spike (0.10), severity (0.25), user_impact (0.20), event_volume (0.25). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Remove the recency-halflife-hours option — no need for runtime tuning yet. Clarify the recency expression by naming the intermediate age_hours. Simplify use_issue_platform check and aggregation lookup.
Co-locate each signal's weight, expression, and description together rather than grouping all weights at the top. Makes it easier to understand each signal in isolation.
The recommended sort is experimental and may be removed. Explicitly reject it in ViewValidator to prevent persisting bad data. Co-Authored-By: Claude Opus 4.6 <noreply@example.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add a new experimental sort option that combines normalized [0,1] signals additively to rank issues:
Unlike the existing trends sort which uses multiplicative combination (where any near-zero factor kills the score), this uses additive combination so signals contribute independently. Weights are tunable via options since the initial values here are almost certainly not ideal.
These signals were chosen primarily because they all exist within snuba and not because they are perfectly optimal, for example severity should ideally be the severity we derive via ML for an issue.