Skill 115 · Prioritizing My Inbox
Subchapter 115.2
references/scoring.mdMarkdown4 KBView on GitHub
The score is a first pass for the hand-built ranking in pool-and-score.md. Use it only on that route, never to reorder the stored personal ranking. It turns 60 to 150 candidates into a rough order so you only judge the top 40 or so carefully. Adjust the weights when the person’s request or the data calls for it, and say what you changed.
score = priority_base × model_multiplier × freshness
+ interest_bonus + needs_me_bonuspriority | Base |
|---|---|
| P0 | 5 |
| P1 | 4 |
| P2 | 3 |
| P3 | 2 |
| P4 | 1 |
null | 1.5 |
priority is null before judgment runs (candidate, some pending_input rows).
1.5 keeps those reports in play without letting them outrank a judged P2.
lifts = [lift(action), lift(fix)] without missing values
if ranking.status == "scored" and scored_at is within ~7 days and lifts:
model_multiplier = 0.5 + 0.5 × min(mean(lifts), 8) / 2
else:
model_multiplier = 1.0action and fix say whether someone will do something. open mostly says whether the title is clickable, so it is a weaker signal for “what should I look at”. Use open only when the other two are missing.action and fix together: most fix positives are also action positives.stale (the text changed after scoring), unscored, and not_available all get 1.0. None of them is a low score.null lift. Treat that as unscored. An old pending_input row with open 0.6 looks strong but says little about today.inbox-ranking-outcomes-list gives each outcome’s horizon and base rate when you need to explain a number.Use updated_at:
| Days since update | Multiplier |
|---|---|
| under 2 | 1.3 |
| 2 to 7 | 1.0 |
| 7 to 21 | 0.7 |
| over 21 | 0.4 |
A report that keeps getting updated is live work. Widen the bands when the person asks for a longer window.
Match each report’s title and summary against the interest profile from Step 1.
strength: high and last_seen in the last 3 days counts in full, medium or older counts at about two thirds, low at about one third.computed.owned or computed.watched by name or id.source_product is in computed.products.works_in.is_suggested_reviewer: true.assignee: "mine" pool).review_decision: approved, because it is close to done.status: pending_input when the report is routed to them.Values are illustrative.
Fresh themed report with a strong model score.
P2, updated 1 day ago, action lift 9.1 and fix lift 4.7, scored yesterday, title matches a high-strength theme, suggested reviewer.
3 × (0.5 + 0.5 × 6.9 / 2) × 1.3 + 2 + 1.5 = 3 × 2.23 × 1.3 + 3.5 ≈ 12.2.
Old routed report with a stale score.
P2, pending_input, updated 30 days ago, open probability 0.6 with null lifts, suggested reviewer, no theme match.
3 × 1.0 × 0.4 + 1.5 + 0.5 = 3.2.
It ranks far below the first example, which matches what the person would pick.
High-priority report owned by someone else.
P1, updated 19 days ago, working, lifts 5.9 and 2.6 scored 2 days ago, weak theme match.
4 × (0.5 + 0.5 × 4.25 / 2) × 0.7 + 1 ≈ 5.4.
It belongs in the list if the person is the reviewer or the theme is strong; otherwise it is a “someone is on it” mention.