4185abe05d
Ideas catalog (docs/ideas/): 25 feature concept documents covering future lore capabilities including bottleneck detection, churn analysis, expert scoring, collaboration patterns, milestone risk, knowledge silos, and more. Each doc includes motivation, implementation sketch, data requirements, and dependencies on existing infrastructure. README.md provides an overview and SYSTEM-PROPOSAL.md presents the unified analytics vision. Plans (plans/): Time-decay expert scoring design with four rounds of review feedback exploring decay functions, scoring algebra, and integration points with the existing who-expert pipeline. Issue doc (docs/issues/001): Documents the timeline pipeline bug where EntityRef was missing project context, causing ambiguous cross-project references during the EXPAND stage. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
75 lines
2.1 KiB
Markdown
75 lines
2.1 KiB
Markdown
# Label Velocity
|
|
|
|
- **Command:** `lore label-flow <from-label> <to-label>`
|
|
- **Confidence:** 78%
|
|
- **Tier:** 3
|
|
- **Status:** proposed
|
|
- **Effort:** medium — self-join on resource_label_events, percentile computation
|
|
|
|
## What
|
|
|
|
For a given label pair (e.g., "needs-review" to "approved"), compute median and P90
|
|
transition times using `resource_label_events`. Shows how fast work moves through
|
|
your process labels.
|
|
|
|
Also supports: single label dwell time (how long does "in-progress" stay applied?).
|
|
|
|
## Why
|
|
|
|
Process bottlenecks become quantifiable. "Our code review takes a median of 3 days"
|
|
is actionable data for retrospectives and process improvement.
|
|
|
|
## Data Required
|
|
|
|
All exists today:
|
|
- `resource_label_events` (label_name, action, created_at, issue_id, merge_request_id)
|
|
|
|
## Implementation Sketch
|
|
|
|
```sql
|
|
-- Label A → Label B transition time
|
|
WITH add_a AS (
|
|
SELECT issue_id, merge_request_id, MIN(created_at) as added_at
|
|
FROM resource_label_events
|
|
WHERE label_name = ?1 AND action = 'add'
|
|
GROUP BY issue_id, merge_request_id
|
|
),
|
|
add_b AS (
|
|
SELECT issue_id, merge_request_id, MIN(created_at) as added_at
|
|
FROM resource_label_events
|
|
WHERE label_name = ?2 AND action = 'add'
|
|
GROUP BY issue_id, merge_request_id
|
|
)
|
|
SELECT
|
|
(b.added_at - a.added_at) / 3600000.0 as hours_transition
|
|
FROM add_a a
|
|
JOIN add_b b ON a.issue_id = b.issue_id OR a.merge_request_id = b.merge_request_id
|
|
WHERE b.added_at > a.added_at;
|
|
```
|
|
|
|
Then compute percentiles in Rust (median, P75, P90).
|
|
|
|
## Human Output
|
|
|
|
```
|
|
Label Flow: "needs-review" → "approved"
|
|
|
|
Transitions: 42 issues/MRs in last 90 days
|
|
Median: 18.5 hours
|
|
P75: 36.2 hours
|
|
P90: 72.8 hours
|
|
Slowest: !234 Refactor auth (168 hours)
|
|
```
|
|
|
|
## Downsides
|
|
|
|
- Only works if teams use label-based workflows consistently
|
|
- Labels may be applied out of order or skipped
|
|
- Self-join performance could be slow with many events
|
|
|
|
## Extensions
|
|
|
|
- `lore label-flow --dwell "in-progress"` — how long does a label stay?
|
|
- `lore label-flow --all` — auto-discover common transitions from event data
|
|
- Visualization: label state machine with median transition times on edges
|