# Reviewer meeting — agenda (for me) > **Audience.** Myself, before the meeting. Not shared with the > reviewer (they have [`briefing.md`](briefing.md) and > [`questions.md`](questions.md) instead). > > **Purpose.** Keep the conversation on the high-stakes items > without slipping into detail-tour mode. **Length:** ~60 min (default; willing to extend if conversation is productive). ## Opening — 5 min - **Thank-you** + ~30 s on why I value their time specifically (Springborn/Bobenko background = best-positioned audience for this material). - **Confirm format**: they've read `briefing.md`? Yes → skip ahead. No → take 3 min to walk through it together via the reviewer-hub URL. ## §1 Architectural tour — 10 min Goal: they leave §1 with a mental map of what's where. 1. Open . 2. Click through: - Doxygen → `discrete_conformal_map_euclidean` (the canonical entry, shows the named-parameter pattern + traits). - `locked-vs-flexible.md` § Summary table. - `dependencies.md` § TL;DR. 3. **Don't** demo running the test suite live unless they ask — they can verify the green badges later. **Cue to move on**: when they have no more "where is X?" questions. ## §2 The five questions — 30 min Goal: get clear answers to as many of the 5 questions in [`questions.md`](questions.md) as possible. Order matters: 1. **Q4 first** (CGAL submission strategy — single package vs five). This sets the framing for the rest. ~5 min. 2. **Q1** (Phase 9c port-literal vs re-derive). ~5 min. 3. **Q2** (Phase 9b-analytic — is the 6× speedup worth ~2 weeks?). May trigger longer math discussion; cap at 10 min and offer to continue async. 4. **Q5** (GC-1 cross-validation co-authorship). ~5 min. 5. **Q3** (CP-Euclidean output_uv_map). ~5 min. **Trap to avoid**: don't relitigate any of the already-made decisions (e.g. Surface_mesh as default, Eigen as backend) unless they bring it up under "anything you'd say no to". Move forward, not sideways. ## §3 The "no" question — 5 min Last paragraph of [`questions.md`](questions.md): *"Is there one architecture decision where you think 'no, that's the wrong call'?"* Ask explicitly. Wait. Don't fill silence. Negative feedback at this phase is the highest-value information of the entire meeting. ## §4 Wrap-up — 5 min - **Summarise**: 1 sentence per Q1–Q5 answer. - **Next steps**: - Items they offered to help on (if any) → I'll send a follow-up email within 48 h. - Items they flagged as worth changing → I'll write a one-page plan + send for sign-off before starting work. - **Cadence**: do they want a periodic update? Once-a-quarter? When hitting Phase 9c milestone? - **Citation**: ask whether they want acknowledgement in the CGAL submission's `THANKS.md`. ## Material I have ready (in tabs) 1. 2. (source) 3. Local terminal in the repo (for any "show me X" requests) 4. `doc/math/hyperideal-hessian-derivation.md` open in editor (for Q2) 5. `doc/architecture/locked-vs-flexible.md` open at "Summary table" 6. This file, [`questions.md`](questions.md), and [`briefing.md`](briefing.md) for backstop. ## After the meeting - 30-min decompression — don't take notes during the meeting beyond bullet-tracking of Q1–Q5 answers; write up a full memo in the 30 min AFTER. - Memo template: ``` Date: ____ Reviewer: ____ Duration: ____ min Q1 answer: ____ Q2 answer: ____ Q3 answer: ____ Q4 answer: ____ Q5 answer: ____ "No" pointer: ____ Action items: [ ] (within 48 h) ____ [ ] (within 2 wks) ____ [ ] (longer term) ____ Cadence agreed: ____ ``` - Store the memo at `doc/reviewer/2026-XX-XX-meeting-notes.md` (gitignored if confidential, otherwise committed).