docs: add feature ideas catalog, time-decay scoring plan, and timeline issue doc

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>
This commit is contained in:
Taylor Eernisse
2026-02-09 10:16:48 -05:00
parent d54f669c5e
commit 4185abe05d
32 changed files with 4170 additions and 0 deletions

67
docs/ideas/mr-pipeline.md Normal file
View File

@@ -0,0 +1,67 @@
# MR Pipeline Efficiency
- **Command:** `lore mr-pipeline [--since <date>]`
- **Confidence:** 78%
- **Tier:** 3
- **Status:** proposed
- **Effort:** medium — builds on bottleneck detector with more stages
## What
Track the full MR lifecycle: creation, first review, all reviews complete (threads
resolved), approval, merge. Compute time spent in each stage across all MRs.
Identify which stage is the bottleneck.
## Why
"Our merge process is slow" is vague. This breaks it into stages so teams can target
the actual bottleneck. Maybe creation-to-review is fast but review-to-merge is slow
(merge queue issues). Maybe first review is fast but resolution takes forever
(contentious code).
## Data Required
All exists today:
- `merge_requests` (created_at, merged_at)
- `notes` (note_type='DiffNote', created_at, author_username)
- `discussions` (resolved, resolvable, merge_request_id)
- `resource_state_events` (state changes with timestamps)
## Implementation Sketch
For each merged MR, compute:
1. **Created → First Review**: MIN(DiffNote.created_at) - mr.created_at
2. **First Review → All Resolved**: MAX(discussion.resolved_at) - MIN(DiffNote.created_at)
3. **All Resolved → Merged**: mr.merged_at - MAX(discussion.resolved_at)
Note: "resolved_at" isn't directly stored but can be approximated from the last
note in resolved discussions, or from state events.
## Human Output
```
MR Pipeline (last 30 days, 24 merged MRs)
Stage Median P75 P90
Created → First Review 4.2h 12.1h 28.3h
First Review → Resolved 8.1h 24.5h 72.0h <-- BOTTLENECK
Resolved → Merged 0.5h 1.2h 3.1h
Total (Created → Merged) 18.4h 48.2h 96.1h
Biggest bottleneck: Review resolution (median 8.1h)
Suggestion: Consider breaking large MRs into smaller reviewable chunks
```
## Downsides
- "Resolved" timestamp approximation may be inaccurate
- Pipeline assumes linear flow; real MRs have back-and-forth cycles
- Draft MRs skew metrics (created early, reviewed late intentionally)
## Extensions
- `lore mr-pipeline --exclude-drafts` — cleaner metrics
- Per-project comparison: which project has the fastest pipeline?
- Trend line: weekly pipeline speed over time
- Break down by MR size (files changed) to normalize