Peer-review pairing is an alphabetical round-robin — ignores who actually works together

[BreadrichEngels]

Problem

The quarterly peer-review flow assigns each member their two reviewees via a positional round-robin over an alphabetical roster — i.e. "review the next two people after you in the cohort list." It's blind to collaboration, so members get assigned to review people they have no working context with, which undermines the value of the review.

This matters because two completed peer reviews gate next-quarter payment eligibility (per #23) — so a context-free reviewer is being asked to produce an evaluation that affects someone's pay.

Evidence

From shared-kb/peer-reviews/state/2026-Q2.json, the assignments follow next-two-in-roster almost exactly (roster = the alphabetical KB-slug list in peer-reviews/config.md):

• marv → otreblig, rade
• otreblig → rade, rathermercurial-eth
• rade → rathermercurial-eth, roloide
• rathermercurial-eth → roloide, ron
• roloide → ron, unai-mettodo
• ron → unai-mettodo, 0xr (wraps around)

Concrete case that surfaced this: rathermercurial-eth was assigned to review roloide (Francisco) and ron — both backend devs they don't work directly with — purely because those two are alphabetically adjacent. Their closest collaborators (unai-mettodo, marv) aren't assigned to them at all. (A couple of pairs deviate slightly — bagelface, cypherbren — suggesting a minor balancing tweak, but the dominant rule is next-two.)

Where

• Pairing logic: profiles/example/plugins/peer-reviews.mjs (per Smithers: migrate remaining multi-step flows (weekly-agenda, peer-review, SD, PM) #111).
• Cohort/config: shared-kb/peer-reviews/config.md; computed assignments in .../state/2026-Q2.json.
• This is effectively the de-facto answer to Workflow: Peer reviews with bot-scheduled meetings #23's open question "Who counts as a valid peer?" — and right now the answer is "whoever's next in the alphabet," which isn't the intent.

Proposed options

1. Pair by collaboration / area — use the owner→project-area mapping and/or real co-working signals (shared repos/PRs/reviews, meeting overlap) to pair people who've actually worked together.
2. Self-select / claim — let each member claim reviewees they worked with, with a min/max so coverage and load stay balanced.
3. Hybrid (recommended) — seed with collaboration-based pairs, fall back to round-robin only to fill coverage gaps; keep the current balance guarantees (everyone reviews ~2, is reviewed ~2).

Given the payment-eligibility stakes, reviewer↔reviewee context should be a first-class input, not alphabetical adjacency.

---

Surfaced by @rathermercurial for the 2026-Q2 cycle; filed via Breadrich.

[BreadrichEngels]

Update — the problem is broader than pairing, and a member has opted out

Live findings from the 2026-Q2 cycle (the scope here has grown past the title):

1. The pairing fix already exists in code — it's just not configured

computeAssignments(members, count, collaborators) in profiles/example/plugins/peer-reviews.mjs now supports the collaboration-seeded matching proposed here (maximum matching over a collaborators edge map, round-robin only to fill gaps). But the Breadchain cohort's peer-reviews/config.md doesn't set a collaborators map, so it falls back to pure round-robin — which is exactly the alphabetical adjacency this issue reported. So for the current setup the fix is largely a config task: populate collaborators in config.md. (Whether round-robin should be the silent default when no collaboration data exists is worth revisiting — see consent below.)

2. No informed consent (new, and the bigger issue)

The flow auto-assigns each member a self-eval + two peer reviews and auto-offers to book meetings, with no opt-in. Because completion gates payment eligibility, members are effectively commanded to review people they may not work with — and to hand over scheduling — without ever agreeing to participate. A member raised exactly this ("stop… get my informed consent before giving me commands or operating on my resources") and opted out of the 2026-Q2 cycle.

• Recommend: make participation and scheduling opt-in; the flow should invite, not assign. Add a first-class opt-out (today there's none — I set escalated:true + an ad-hoc optedOut:true on the member's state record to stop the nudges).

3. Google Calendar is assumed (new)

auto_schedule + matchTaskIpc assume Google Calendar (free/busy lookups + booking gcal events), and the availability ask says "I'll… put the meetings on the calendar." Members who don't use gcal get an ask/operation that doesn't apply.

• Recommend: don't assume a calendar — make scheduling opt-in and ask the member's preferred method (or drop calendar I/O and just propose times), and skip entirely for anyone who hasn't opted in.

4. Minor: escalation copy

escalationPost here uses the same "📝 I don't have 's … yet" framing that #140 fixes for the weekly-agenda flow. Less wrong here (reviews genuinely aren't pre-drafted), but worth aligning to the same non-"missing" voice.

Surfaced by @rathermercurial for 2026-Q2; they've been opted out of the current cycle. cc @RonTuretzky.