Skip to content

docs(design): backlog community engagement -- Draft 1 (#31)#4

Open
akenel wants to merge 1 commit into
mainfrom
docs/bl-community-engagement
Open

docs(design): backlog community engagement -- Draft 1 (#31)#4
akenel wants to merge 1 commit into
mainfrom
docs/bl-community-engagement

Conversation

@akenel

@akenel akenel commented May 23, 2026

Copy link
Copy Markdown
Owner

What

Draft 1 design doc for making the BL module a real two-way street with users — not just an admin tracker.

Why

Your framing 2026-05-23 morning:

"we need the bl to work properly end to end so its not just for me but to invite users to properly fix issues and add features they want"

Task #31. Closes the bigger design conversation that task #30's API fix opened up.

Read flow

The doc follows the stage-based review pattern we proved with LP CLI:

  1. Stage 1 (you, on this PR): read the doc, leave inline comments on any section that needs change
  2. Stage 2 (me): fold notes into Draft 2
  3. Stage 3: review wireframes per PR (each milestone PR gets its own UI sketch)
  4. Stage 4: locked design → ship M1

Don't merge until Stage 4 OR until we ship M1 to validate the smallest piece is right.

Highlights

Scope: 4 PRs over ~3 weeks M1 surface resolution info in UI · M2 comment thread · M3 edit-own-item · M4 my items view + notifications
Deferred upvote · public RSS feed · magic-link auth (own design doc)
Data model Additive only for M0-M3 — no migrations needed yet
Auth model proposal reporter_user_id becomes "owner" for edits while status==pending
5 open questions Anonymous reclaim, comment threading, notification granularity, cross-realm visibility, public detail-page readability

Recommendation (LP CLI lesson applied)

Don't lock the full design before shipping M1. M1 is small (surface resolution_sha + resolution_note in UI), highest visual impact, no auth/ownership complexity. Ship it, see what users do, adjust the rest.

Generated with Claude Code (Opus 4.7).

Draft 1 of the design for making the BL module a real two-way street
with users, not just an admin tracker.

Driven by Angel's framing 2026-05-23:
"we need the bl to work properly end to end so its not just for me
but to invite users to properly fix issues and add features they want"

Covers:
- Current state inventory (what's working, what isn't)
- 8 gaps sized rough
- User stories for Reader / Filer / Maintainer / Champion
- Scope: 4 PRs in / 4 features deferred / 2 pre-existing concerns
  separated
- Data model additions (additive only, no migrations needed for M0-M3)
- API surface additions
- ASCII wireframes for the proposed UI changes
- Auth + ownership model proposal
- 5 open questions for Stage 2 review
- Milestones M0 (today, task #30 done) -> M1-M4 over ~3 weeks
- Success metrics for 30-day-post-ship evaluation
- Risks (scope creep, auth friction, CI schema drift)

Stage-based review like we did with LP CLI:
- Stage 1: per-section notes
- Stage 2: fold in -> Draft 2
- Stage 3: wireframes per PR
- Stage 4: locked design

Recommend ship M1 (smallest, highest visual impact) BEFORE locking
the full design, per LP CLI lesson on over-engineering before
shipping anything.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant