Group and prioritise the 571 open langwatch issues into a set the team can pull from

[rogeriochaves]

What

Group every open issue in langwatch/langwatch and come out of the week with a
ranked, grouped set that anyone can pull work from on Monday 2026-08-17. Not a
review, and not a plan to do it later. A list with an order.

The real number

571 open issues in langwatch/langwatch on 2026-08-09, counted over the REST
issues endpoint with pull requests excluded. The call said "about 600" and the
older figure of 500 is out of date, partly because 105 issues moved to
langwatch/tasks this week. For scope: langwatch/tasks holds 105 more open
issues and langwatch/langwatch-saas holds 192. Decide on day one whether those
are in this pass or a second one.

What the labels look like today, as a starting shape and nothing more:

	count
labelled bug	115
labelled tech-debt	73
no labels at all	147
no native issue Type set	529
median age	45 days

The method the call agreed

From the 2026-08-07 call on bug prioritisation, tech debt grouping and agent
lanes. Follow this, do not invent a new one.

1. Split bugs from tech debt first. Bugs come first. Tech debt is lower
   priority right now.
2. Inside bugs, rank by what people actually use. A bug in a flow people hit
   every day beats a bug hidden behind an edge case.
3. Group into parent issues with children, not epics. A parent issue is a
   unit you can hand to one worker with the sentence "solve all of these".
4. Pick the lane per group: agent or human. Agents take tech debt and small
   bug clusters. Humans drive the complex flows. Login, invites and identity
   already have a human owner and stay out of the agent lanes, because you cannot
   ship half a login.
5. Agent groups ship as stacked PRs, never one big PR. Small PRs review
   faster and conflict less. One high-priority bug must never sit behind a mega
   PR.

Dates

Monday 2026-08-10 to Friday 2026-08-14. Friday is the deadline.

Done means

• Every open issue in langwatch/langwatch sits in exactly one group, or is
  explicitly closed or dropped out of the set
• Each group is a parent issue with its children linked
• Each group is marked bug or tech debt
• Each group is marked agent lane or human lane, with one line of reason for
  the human ones
• The groups are in priority order top to bottom, not just bucketed
• That order is on the board, so on Monday 2026-08-17 anyone can pull the next
  thing without asking what is next

---

Source: the 2026-08-07 call on bug prioritisation, tech debt grouping and agent
lanes. Counts measured 2026-08-09.

[drewdrewthis]

Planning comment — create-issue plan step
v2 — 2026-08-11: adds the complete focus-label list and label specs so this comment is self-contained.

Approach

Make ordering fully derivable from labels — focus area → priority → recency — so leadership can prioritize foci, not just individual tickets. Scope: all open issues across langwatch/langwatch, langwatch/langwatch-saas, and langwatch/tasks (~868 total); issues may move between repos where they fit better.

Label taxonomy (created first, identical in all three repos)

Focus labels — F<nn>:<area>, zero-padded rank + area. Rank ordered by real product usage (30-day analytics) where measurable, approved by @drewdrewthis. Re-ranking is a label rename, which carries all tagged issues along. The full set:

Label	Covers
F01:traces	Traces, messages, observability, analytics views
F02:sdk	SDKs, integrations, ingestion path
F03:scenarios	Scenarios / agent simulations
F04:evals	Evaluations, online evals, experiments
F05:onboarding	Welcome, first-run, signup flows
F06:auth-identity	Login, invites, orgs/teams/members
F07:prompts	Prompt management
F08:datasets	Datasets
F09:studio	Optimization studio / workflow editor
F10:annotations	Annotations, human feedback
F11:billing	Subscription, usage, billing
F12:infra-clickhouse	ClickHouse, data storage/queries
F13:mcp	MCP server and tools
F14:langy	Langy in-product assistant
F15:ui-ux	Cross-cutting UI/UX polish
F16:dx	Internal developer experience
F17:docs	Documentation

(F12/F13 are judgment-ranked — backend areas are invisible to pageview analytics.)

Priority labels — existing standard, normalized in all three repos:
P0 - critical (production broken, data loss, team blocked) · P1 - high (core feature broken/major regression, current sprint) · P2 - medium (notable bug or important improvement, next sprint) · P3 - low (polish, nice-to-have, backlog). Lowercase p0–p3 variants and partial sets get renamed to this standard.

Size labels — size:XS, size:S, size:M, size:L, size:XL. Anything size:L or larger must become a parent issue with sub-issues.

Cleanup — duplicate labels merged (e.g. needs investigation → needs-investigation).

Phases

1. Taxonomy (Tue): create/normalize all labels above in the three repos.
2. Classification sweep (Tue–Wed): every open issue gets bug/tech-debt, one F<nn>:, one size:, one P label; stale/duplicate/obsolete issues collected into a propose-close list for one-pass owner approval — closes are proposed, never unilateral.
3. Grouping (Wed–Thu): related issues bundled under parent issues with linked children — a group is a set shippable together as one PR or a PR stack. Each group marked agent-lane or human-lane with reason (login/invites/identity stays human).
4. Board (Fri): ranked order reflected on the project board; Done checklist in the issue body verified item by item.

Key decisions

• Focus rank lives in the label name (sortable everywhere); leadership owns the F-order.
• "Groups" = parent issues with children, not epics.

Risks / open questions

• Label-only changes; no project-board field mutations (option edits wipe existing field values).
• Propose-close list size unknown until the sweep runs.

Acceptance criteria

The Done checklist in the issue body, plus: label taxonomy present and identical in all three repos; every open issue carries exactly one F<nn>:, one P, one size label.

---

Posted by the assistant session on behalf of Drew (drewdrewthis).

---

v3 — 2026-08-11: two additions from the owner.

Assignment (added)

When this is done, every open issue is assigned — the goal is that everyone knows what they need to work on on Monday (2026-08-17). Assignment pass runs with Phase 3–4: parent issues get owners; human-lane groups go to the responsible person, agent-lane groups to the agent identity. A proposed owner mapping goes to @drewdrewthis for one-pass review before it's applied.

System documentation (added)

How this whole system works (label taxonomy, ordering rule, grouping/parent convention, assignment rule, maintenance duties) is documented in the Project 5 description and README so the kanban-keeper agent can keep it going after this one-time pass.

[drewdrewthis]

Phase 1 (taxonomy) — complete and verified. Posted by an agent working on behalf of @drewdrewthis.

State

The taxonomy is now byte-identical across all three repos (langwatch, langwatch-saas, tasks) — 30 labels, matching name, colour and description in each:

• Focus — F01:traces … F17:docs (all 17, per the v2 table above)
• Priority — P0 - critical · P1 - high · P2 - medium · P3 - low
• Size — size:XS size:S size:M size:L size:XL
• Type — bug · tech-debt · feature
• Workflow — needs-investigation

Most of this was already in place. This pass closed the remaining gaps, all in langwatch-saas: created feature and needs-investigation; normalised P2 - medium and tech-debt (colour + description drift). No stray case/space variants remain in any repo (no lowercase p0–p3, no needs investigation). No project-board field options were touched.

Verification: label sets dumped from all three repos and diffed on name+colour+description — identical, 30/30.

Phase 2 baseline (measured today)

899 open issues: langwatch 590 · langwatch-saas 202 · tasks 107.

	has focus	has priority	has size	has type	no labels
langwatch (590)	12	240	13	261	151
langwatch-saas (202)	6	96	6	74	64
tasks (107)	0	29	0	34	15

So focus and size are effectively greenfield (~2% covered) and the sweep is ~880 issues × 4 labels. That is the Tue–Wed workload.

One decision needed

feature vs enhancement. The ratified taxonomy names the third type feature, but enhancement is what the repos actually use: 95 open issues carry enhancement (58 / 22 / 15) against 21 with feature (16 / 0 / 5). Both labels exist in all three repos, so the type dimension is currently ambiguous.

Proposal: keep feature as canonical per the ratified README, and fold the 95 enhancement issues into it during the Phase 2 sweep — every one of those issues is being touched anyway, so this costs no extra pass. enhancement is then left empty and can be retired later.

Proceeding on that basis unless you say otherwise. It is reversible, and flagging it now rather than after 900 issues are labelled.

Phase 2 (classification sweep) starts next.

[drewdrewthis]

Phase 1 addendum — full verification + a second decision. Posted by an agent working on behalf of @drewdrewthis.

Verification, tightened

My previous comment claimed the taxonomy was identical across the three repos, but the diff behind that claim only covered the focus/priority/size labels by pattern, not the full 30 by name. Re-ran it as an exact-name match on the explicit 30-label list, diffing name|colour|description:

• langwatch 30/30 · langwatch-saas 30/30 · tasks 30/30
• langwatch vs langwatch-saas → identical
• langwatch vs tasks → identical

So the claim holds, now on evidence that actually covers all 30.

Two labels carry an empty description (feature, needs-investigation) — consistent across all three repos, matching how they already existed in langwatch and tasks. Say the word if you want descriptions written for them.

Second decision: the epic label

The system doc says groups are parent issues with sub-issues, not epics. But an epic label exists in all three repos and 18 open issues carry it (14 / 3 / 1) — several are explicitly titled EPIC: or PROPOSAL: and are, in substance, exactly the grouping unit Phase 3 is meant to produce.

So these are less a conflict than a head start: they are pre-existing group candidates.

Proposal for Phase 3: treat the 18 epic-labelled issues as the first candidate parent issues rather than inventing new ones over the top of them; convert them to parents with linked sub-issues; retire the epic label at the end of the pass once the parent/child relationship carries the meaning. Nothing gets closed.

Flagging rather than deciding, since retiring a label and the "not epics" wording are both yours to call. Phase 2 does not depend on this — I will proceed with the classification sweep meanwhile.

[drewdrewthis]

Type axis corrected — five types, not three. Posted by an agent working on behalf of @drewdrewthis.

Both questions from my last comment are answered by the owner, and the answer is that I had the model wrong. feature and enhancement are distinct and both stay. epic stays. Recording the corrected definitions here since they now govern the Phase 2 sweep, and the board README still documents the older three-type set.

Type	Meaning	User-visible?
bug	Something is broken or behaves contrary to requirements	Yes — incorrect behaviour
feature	New functionality that wasn't there before	Yes — new capability
enhancement	Improvement to existing functionality (performance, UX, capabilities)	Often — better behaviour
tech-debt	Suboptimal design or implementation that increases the future cost of change	No — internal
refactor	Code restructuring without changing external behaviour, often to reduce debt	No

epic and proposal are separate axes, not type values: epic groups related work for board visibility and reasoning; proposal marks a proposal for work rather than committed work.

Applied

• refactor did not exist in any of the three repos — created in all three.
• proposal was missing in langwatch-saas — created, matching the other two.
• Descriptions on bug / feature / enhancement / tech-debt / epic normalized to the definitions above in all three repos. enhancement previously carried GitHub's stock "New feature or request", which is the exact conflation this table resolves.
• feature and refactor were given real colours rather than the default grey, so they can't be mistaken for auto-created labels.

Canonical set is now 34 labels — 17 focus, 4 priority, 5 size, 5 type, plus epic, proposal, needs-investigation. Verified by exact-name match diffing name+colour+description: 34/34 in each repo, langwatch vs langwatch-saas identical, langwatch vs tasks identical.

Current spread on the type axis, all open issues: bug 160, tech-debt 111, enhancement 95, feature 21, refactor 0, epic 18, proposal 13.

Still open

The board README documents the older three-type taxonomy and needs updating to match the table above. I'll fold that into the system-documentation item rather than editing it piecemeal now.

[drewdrewthis]

Agent working on behalf of @drewdrewthis — Phase 2 prep: priority rubric.

The planning comment defines P0–P3 in one line each. That is a vocabulary, not a decision procedure — two people can apply it to the same issue and disagree. Since the whole point is that ordering be derivable from labels, the P axis has to be decidable by one reader without asking. This expands the existing definitions; it does not replace or contradict them.

What P measures

P is severity of consequence, not strategic importance. Focus rank (F01–F17) already carries importance — the board orders focus → priority → recency, so P only ever competes within a focus area. A P1 in F14:langy does not outrank a P2 in F02:sdk if SDK ranks higher. This is why "it's important to us" is never a reason for P0; that argument belongs in the focus rank.

P is also not effort (that's size:), and not kind of work (that's the type label).

The four levels

The Response commitment column is provisional — see the first item under "Two things I need from you". It is my reading of the planning comment's sprint language, not a ruling, and it is the one column here that binds people's time rather than just describing a label.

Label	The test — is this true right now?	Response commitment (provisional)	Example
P0 - critical	Production is broken, data is being lost or corrupted, or the team is blocked from shipping. Ongoing, not hypothetical.	Drop other work. Same day.	Ingestion pipeline dropping traces; auth outage locking users out; CI red on main.
P1 - high	A core feature is broken or badly regressed for real users, and there is no reasonable workaround. Or: blocks a committed deliverable.	Current sprint.	Evals fail silently on a common config; a documented SDK method throws.
P2 - medium	A notable bug with a workaround, or an improvement that clearly pays for itself. Real, not urgent.	Next sprint.	Confusing error message that costs support time; missing pagination on a long list.
P3 - low	Polish, nice-to-have, speculative, or a real problem nobody has hit yet.	Backlog. No commitment.	Copy tweaks; refactors with no forcing function; "would be nice if".

Decision procedure — first match wins

1. Is something broken in production right now, losing data, or blocking the team from shipping? → P0. If it was true last week and is fixed or mitigated now, it is not P0 anymore.
2. Is a core feature broken/regressed for real users with no reasonable workaround? → P1.
3. Does it have a workaround, or is it an improvement with a clear payoff? → P2.
4. Everything else → P3.

If you're torn between two levels, pick the lower one and say why in a comment. Escalating later is cheap; a backlog where everything is P1 is not recoverable.

What P0 is not

P0 is the one label that costs the whole team, so it needs the tightest definition:

• Not "the customer is angry" — that's usually P1 with a workaround.
• Not "this has been open too long" — age is the third sort key already; it does not promote severity.
• Not "this is strategically important" — that is a focus-rank argument.
• Not "it will be critical if we don't fix it" — future risk is P1 or P2. P0 is a present tense.

Expect P0 to be near-empty in steady state. Today there is exactly 1 open P0 across all three repos, and that is the correct order of magnitude. If P0 climbs past a handful, the label has stopped meaning anything.

Tie-breakers

• Breadth beats depth. All users mildly affected outranks one user severely affected, at the same severity tier.

• Silent beats loud. A wrong answer with no error outranks a crash, because nobody reports the wrong answer.

• Data loss is never below P1. Even with a workaround, even if rare.

• Security and auth default one level higher than the tier the procedure lands on — but the bump stops at P1 and never reaches P0. (Proposed by me, not sourced to a prior ruling — it matches the handoff's instinct that login/invites/identity are always human-lane. Say the word and I'll drop it.)

  Correction, 2026-08-11. As first written, this tie-breaker had no ceiling, and applying it to langwatch/langwatch produced 11 P0s in the first 200 issues — mostly unenforced-authz and policy-bypass bugs. That directly contradicts "expect P0 to be near-empty" three sections up. The contradiction was mine, in a rule I had already marked as unsourced. Capping the bump at P1 resolves it: a latent authz bypass is a core feature broken with no workaround, which is the P1 test, and it reaches P0 only if it is also presently breaking production, losing data, or blocking the team. Under the cap, langwatch yields a handful of P0s rather than dozens.

Calibration

Current spread across all three repos, open issues with a P label — 364 of 896 open, measured 2026-08-11, so the sweep labels the remaining 532. No issue carries more than one P label. (These figures drift as issues close; an earlier count in this thread read 365/899 and was simply taken two days sooner.)

	P0	P1	P2	P3
langwatch	1	22	121	95
langwatch-saas	0	15	62	19
tasks	0	0	8	21

A healthy backlog is bottom-heavy — most work is P2/P3, and that is not a failure. If the sweep produces a large P1 tier, that is a signal the tier was applied to "important" rather than "broken with no workaround", and I'll flag it rather than ship it.

Two things I need from you

1. The response-commitment column binds the team, not just the labels. I've written what the planning comment implies (P0 same-day / P1 current sprint / P2 next sprint / P3 backlog). Confirm or correct — I'll apply the rubric either way, but that column shouldn't be mine to set.
2. Confirmed as agreed unless you say otherwise: I now set P0 where the rubric's step 1 is met, rather than proposing it. Every P0 I set will be listed explicitly in the Phase 2 report for one-pass review.

Once confirmed, this goes into the Project 5 README alongside the label taxonomy, so the kanban-keeper agent applies the same test on new issues.

---

Also recording two changes from today so they're on the issue and not just in chat:

• size:L / size:XL are no longer converted into parent issues. The planning comment says anything size:L or larger must become a parent issue with sub-issues. That is suspended — L and XL stay as single issues, and the split becomes a follow-up we may not do. The size labels still get applied in the sweep; only the conversion obligation is dropped. This removes the largest piece of Phase 3.
• P0 authority granted (see item 2 above).