Bringing Four Flagship Budgets Into One View  🔗 **Source:** [Bringing Four Flagship Budgets Into One View](https://make.wordpress.org/community/2026/09/11/bringing-four-flagship-budgets-into-one-view/) > [!note]+ Document Notes > tags: [wordcamp, event-budgeting, cash-flow-forecasting, multi-currency-accounting, wordpress-community] > author: Harmony Romo > source: Make WordPress Community > reference: https://make.wordpress.org/community/2026/09/11/bringing-four-flagship-budgets-into-one-view/ > date created: 2026-09-12 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Bringing four flagship budgets into one view > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References (in-page) - [Bringing four flagship budgets into one view](https://make.wordpress.org/community/2026/09/11/bringing-four-flagship-budgets-into-one-view/), Harmony Romo, published 2026-09-11 19:25 UTC - Post tags: [#community-team](https://make.wordpress.org/community/tag/community-team/), [#finances](https://make.wordpress.org/community/tag/finances/), [#flagship](https://make.wordpress.org/community/tag/flagship/) - The post body contains no outbound links. The templates, the rollup file, the spreadsheet platform, and the accounting system are described but not linked or named (checked against the stored HTML, which holds one link: a sidebar image). ## 📝 Summary - **What happened.** Harmony Romo posted on the Make WordPress Community blog about a new budget setup for the four 2027 flagship WordCamps: Europe (Spain), Asia (Malaysia), US, and a first WordCamp India. Each event runs between $500K and $1M of income and expense. - **The setup.** Each event keeps its own budget file. Every file carries one identical summary tab, and budget lines are tagged to real account names from the books. A single rollup file reads the four summary tabs, converts to US dollars, imports actual dollars paid from the accounting ledger, and turns per-line due dates into a monthly cash calendar. - **Why it matters.** 2027 has four flagships instead of three, so large payments can collide. The post's example is three events with large venue deposits landing in the same three weeks, a risk no single event team could see. - **Key stakeholders.** The four organizing teams (mostly volunteers, per the post), the author's finance role, whoever runs the accounting system, and the sponsors and attendees whose money funds the events. - **Risks and tradeoffs.** Due dates are optional, so the cash calendar only covers lines teams date. The cash calendar shows outflow only; the post doesn't mention income timing. The post doesn't say which exchange rate converts forecasts to dollars. The author calls it a first version and has asked every team for feedback. - **Bottom line.** The fix standardizes one interface (the summary tab) and one vocabulary (account names), reads actuals from the books instead of asking teams for them, and leaves everything else to the teams. ## 📖 Main Content - **The problem sat between the budgets.** The author says each budget was reasonable alone. Three gaps caused the trouble: no cross-event view of payment timing, categories that differed per file (so the author mapped them by hand "rarely and late"), and currency handled differently per file. - **Why a live exchange rate is worse than a fixed one.** A live market rate changes an event's dollar total every day, so no report reconciles to the previous one. It also applies today's rate to a payment made months ago, which is the wrong rate for that payment. - **Design principle: ask the teams for as little as possible.** Teams keep their own line items, currency, and working style. The shared requirements are the identical summary tab and account-name tags. Most template lines arrive pre-tagged, so teams check tags instead of creating them. Due dates are optional. - **Two data sources, split by who owns them.** Budgets and forecasts come from the teams in local currency. Actual spend comes from the accounting ledger in dollars, which already records the actual exchange rate and local-currency amount on each foreign payment, with each expense tagged to its event. An importer in the rollup file reads it. - **Read-only direction.** The rollup pulls from the event files; nothing writes back into them, and nobody emails files. - **The cash calendar.** The ledger can't show obligations nobody has invoiced yet, such as a venue balance due next July. Due dates on budget lines fill that gap, and the rollup shows expected outflow by month with all four events side by side. - **Review cadence.** Kickoff (budget drafted and categorized), approval (cap agreed; the budget number stops moving), variance checks at 90, 60, and 30 days out (the 60-day check looks across all four events for cash), and a month-after review comparing actuals to forecast. Between those points, the author only contacts a team if something flags. **Terms** - *Flagship WordCamp*: the large regional WordCamps. The post lists Europe, Asia, US, and India for 2027. - *Rollup*: a file that aggregates summary figures from several source files. - *Variance check*: a comparison of budget against forecast or actual spend. - *Ledger*: the accounting system's record of transactions. - *Cash calendar*: expected outflow grouped by month. **Uncertainties and gaps** - The post doesn't name the spreadsheet platform, the accounting system, or how the "live" pull and the importer work. - The post argues against live rates, then says the rollup "converts everything to dollars" without naming the rate used for budgets and forecasts. Actuals use the booked rate; forecasts need a rate too. - The outcome claims ("Now that shows up as a spike") describe design intent. The closing says no full cycle has run yet. ## 🗒️ Notes - 2027 flagships: Europe (Spain), Asia (Malaysia), US, India (first edition). Four in one year, up from three. - Size per event: $500K–$1M of income and expense. - Budget builders: a different team per event, mostly volunteers, negotiating venue contracts, catering minimums, and deposits across timezones. - The author's own admission: the finance side was "more reactive than proactive." - Gap 1, no cross-event view: each team saw its own payment schedule; no one saw deposit collisions across events. - Gap 2, file shapes: categories varied, so totals needed manual mapping each time. - Gap 3, currency: fixed rate in some files, live market rate in others. - Build: four event files plus one rollup. - Integration contract: one identical summary tab in the same place in every file. - Categories: real account names from the books; year-end re-keying goes away; budget and accounting use one vocabulary. - Rollup behavior: reads all four summary tabs live, converts to dollars, writes nothing back. - Actuals: read from the ledger by event through an importer; the ledger holds the actual rate and local amount per foreign payment. - Local teams watch their budget in their own currency; the dollar view belongs to the author. - Due date per budget line → monthly cash calendar across all four events; a collision shows as a spike in one row months before invoices exist. - A blank due date means budgeted but not scheduled. - Cadence: kickoff → approval (number freezes) → 90/60/30-day variance checks (60-day is cross-event cash) → month-after actuals review. - Status: templates are with the 2027 teams; feedback requested; the author plans a follow-up post after a full cycle, "including the parts that didn't work." - Spelling: the post uses British forms ("categorised," "organising"). ## 📚 References - [Bringing four flagship budgets into one view — Make WordPress Community](https://make.wordpress.org/community/2026/09/11/bringing-four-flagship-budgets-into-one-view/) (primary source) - [Make WordPress Community: #flagship tag archive](https://make.wordpress.org/community/tag/flagship/) - [Make WordPress Community: #finances tag archive](https://make.wordpress.org/community/tag/finances/) - [WordPress/wordcamp.org repository](https://github.com/WordPress/wordcamp.org) — context, not cited by the post: the `wordcamp-payments` plugin contains `includes/budget-tool.php` and `includes/wordcamp-budgets.php`, an event budget tool inside WordCamp.org (verified by directory listing 2026-09-12) ## 🗣️ Paraphrase - **Paragraph 1.** Four flagship WordCamps happen in 2027 (Spain, Malaysia, US, and a first India edition), each handling $500K to $1M. - **Paragraph 2.** Separate teams build each budget their own way, and the author says that's fine: the mostly volunteer organizers know their events and shouldn't be told how to budget. - **Paragraph 3.** The weak point was the author's oversight role. Scattered files kept the author reactive, and four events in one year make payment timing matter more. - **"Where the problem actually was."** The budgets were sound individually; the issues sat between them. - **No view across events.** Teams saw their own schedules, but nobody saw several large deposits due in the same window, a cash risk visible only in aggregate. - **Every file a different shape.** Inconsistent categories meant hand-mapping, so consolidation happened rarely and late. - **Currency.** Mixed fixed and live rates. Live rates make totals drift daily, break reconciliation, and misstate past payments. - **"What I built."** Four event files and one rollup, designed to ask teams for as little as possible. - **One file per event.** Teams keep their own style; the only shared requirement is an identical summary tab, which is the whole integration. - **Account-name categories.** Lines are tagged to real accounts from the books, removing year-end re-keying and giving budget and accounting one vocabulary. Templates come mostly pre-tagged. - **Live rollup.** It reads each summary tab, converts to dollars, and never writes back. - **Actuals from the books.** Teams watch local currency; the author tracks dollars. - **Ledger import.** The accounting system already stores actual rates, local amounts, and event tags, so the rollup imports actual dollars paid per event. - **Clean split.** Teams supply budgets and forecasts in local currency; the books supply actuals in dollars; nobody duplicates work. - **Knowing what's coming.** The ledger shows payments made, not future obligations that haven't been invoiced. - **Due dates.** Each line gets a due date, and the rollup builds a monthly outflow calendar across all four events, exposing collisions months ahead. - **Optional dates.** A blank date means the money is budgeted but not scheduled. - **"The process from here."** Check-ins happen at agreed points so teams don't feel watched: kickoff, approval with a frozen number, 90/60/30-day variance checks with a cross-event cash look at 60 days, and a month-after actuals review. - **Between check-ins.** Contact happens only when something flags. - **"In closing."** Four teams did sensible work; the failure was that nobody owned the space between their spreadsheets. - **Final paragraph.** Templates are with the 2027 teams, feedback is requested, the author expects problems in this first version, and promises a follow-up after a full cycle. ## 📰 Newsletter **Four flagships, one cash calendar.** 2027 brings four flagship WordCamps (Europe in Spain, Asia in Malaysia, US, and the first WordCamp India), and each one moves $500K to $1M. On Make Community, Harmony Romo explains how the budgets now roll up: every team keeps its own spreadsheet and currency, fills in one identical summary tab, and tags lines to real account names. A rollup file reads the tabs, pulls actual dollars from the books, and turns due dates into a month-by-month cash calendar, so three venue deposits in the same three weeks show up months before the invoices. If you organize a WordCamp, run a meetup budget, or manage money across several volunteer teams, read the section on why a live exchange rate is worse than a fixed one. The post is a first version, and the author has promised a follow-up covering what didn't work. 👉 [Read "Bringing four flagship budgets into one view"](https://make.wordpress.org/community/2026/09/11/bringing-four-flagship-budgets-into-one-view/) ## ✅ Action Items #### DevRel - Developer advocacy: turn the "one identical summary tab" pattern into a short talk or demo on minimum-contract integration between volunteer teams. - Education: build a 30-minute workshop for new flagship and regional organizers on tagging budget lines to account names and adding due dates. - Developer experience: if the rollup uses a scriptable importer, ask for a published, generic version of the template set with a sample ledger export. - Developer marketing: Not applicable to this source — the post is internal finance operations, not a product or campaign. - Community management: track feedback from the four 2027 teams in one public thread so the promised follow-up has data. - Internal/external/cross-project: agree on the check-in dates (kickoff, approval, 90/60/30, month-after) with each team up front. #### OSPO - Policy & Governance: document who approves the budget cap and who decides when the 60-day cross-event check flags a cash collision. - License Compliance: if templates get published, pick a license (for example CC0 or GPL-compatible) before release. - Security Management: review access to the rollup and ledger importer; volunteer-owned files linked to a finance file need least-privilege sharing. - Software Inventory: record which spreadsheet platform, importer, and accounting export the rollup depends on; the post names none. - Developer Support: write a one-page recovery procedure for when a team renames or moves its summary tab and the rollup breaks. - Community Engagement: invite regional WordCamp and do_action organizers to comment on whether the templates scale down. - Strategic Alignment: add two KPIs: days of warning before a cross-event cash collision, and the forecast-to-actual gap at the month-after review. #### Community - Maintainers: keep the template changelog public so version 2 changes are traceable after the first cycle. - Contributors: pair each first-edition team (WordCamp India 2027) with a returning flagship budget lead for the first variance check. - Sponsors: publish an aggregate cash calendar or budget-vs-actual summary after the cycle; the account-name tagging makes that possible without re-keying. - Ecosystem: share the live-rate reconciliation lesson with other open source conference organizers who budget in several currencies. #### WordPress - Core: Not applicable to this source — no software change. - Core Performance: Not applicable to this source — no software change. - Core AI: Not applicable to this source — no AI component. - **Core Program Team:** borrow the cadence (freeze the number at approval, checks at fixed intervals, contact only on a flag) for cross-team release coordination. - Mobile: Not applicable to this source — no app component. - Playground: Not applicable to this source — no software demo. - Community: add the template set and cadence to the WordCamp organizer handbook once the first cycle validates it; compare it with the existing budget tool in the WordCamp.org `wordcamp-payments` plugin. - Training: create a Learn WordPress lesson on multi-currency event budgeting for organizers. - Marketing: Not applicable to this source — internal operations post. - Support: Not applicable to this source — no user-facing support surface. - Design: design a readable cash-calendar view (monthly outflow by event, collision highlighting) if the rollup ever moves into WordCamp.org tooling. - Documentation: document the summary-tab spec (cell positions, required fields) so teams can't break the integration by accident. - Photos: Not applicable to this source. - TV: Not applicable to this source. - Polyglots: check that template labels and instructions work for teams that budget in other languages and currencies; the post uses British spellings on an en-US site. - Accessibility: make sure the template and rollup don't rely on color alone to flag a spike (WCAG 1.4.1). - Meta: evaluate whether the WordCamp.org budget tool (`budget-tool.php`) could import a flagship summary tab so flagships and regional events share one system. - CLI: Not applicable to this source. - Hosting: Not applicable to this source. - Tide: Not applicable to this source. - Openverse: Not applicable to this source. - Themes: Not applicable to this source. - Plugins: Not applicable to this source. #### The WPOCC - Programs: use a due-date cash calendar for microgrant and stipend payouts so several large disbursements don't land in one window. - Projects: run a governance clinic on "own the seam" — assigning an owner to the space between autonomous teams. - Funding experiments: model transparent ledgers on this split: commitments from teams in their currency, actuals from the books at the booked rate. #### FAIR - Technical independence: keep the aggregate view read-only against contributor-owned data, as this rollup does. - Policies and covenants: freeze approved budget caps and publish variance at defined checkpoints. - Productized governance artifacts: package the summary-tab spec, cadence, and account mapping as a reusable budget charter. ## 🧪 Hypotheses 1. The cash calendar flags cross-event deposit collisions at least 90 days before the payment is due, where the old setup surfaced them only after invoicing. 2. Reading actuals from the ledger at the booked rate makes consecutive dollar reports reconcile for all past payments, where live-rate files did not. 3. Pre-tagging template lines to account names reduces year-end re-keying time for 2027 flagships compared with 2026. 4. Because due dates are optional, dated coverage is higher for venue deposits than for smaller or later obligations such as catering or AV balances. 5. Freezing the budget number at approval produces a smaller forecast-to-actual gap at the month-after review than events whose budget kept moving. 6. Team-reported time spent on finance reporting stays flat or drops versus 2026, testing the "ask for as little as possible" principle. ## 📊 Methodology - **Design:** before/after comparison, 2026 flagships (three events, old process) against 2027 flagships (four events, new process), plus within-2027 comparison across events. - **Data sources:** rollup snapshots saved at each checkpoint (90/60/30 days, month-after); ledger exports with booked rates and event tags; template version history; team feedback responses. - **Measures:** - Lead time: days between the first cash-calendar flag and the payment due date (H1). - Reconciliation: count of past-payment dollar differences between consecutive reports (H2). - Re-keying effort: hours logged by finance staff at year end (H3). - Coverage: share of budget lines and share of budget dollars carrying a due date, by category (H4). - Accuracy: absolute percentage gap between approved budget and month-after actuals (H5). - Burden: a short survey of each team's monthly time on finance reporting (H6). - **Analysis:** descriptive comparison (four events is too few for statistical tests); qualitative coding of team feedback against the three original gaps. ## ❓ Questions - Which exchange rate converts budgets and forecasts to dollars in the rollup: a fixed budget rate set at approval, or something else? - The cash calendar shows outflow. Where does income timing (sponsorship payments, ticket revenue) appear, and can the rollup show a net cash position? - WordCamp.org has an event budget tool (`wordcamp-payments/includes/budget-tool.php`). Why do flagships use separate spreadsheets, and should the two converge? - What happens when a team renames, moves, or restructures its summary tab? Does the rollup fail loudly or return wrong numbers quietly? - Who can edit the rollup and the importer, and who can see the ledger data it pulls? - When the 60-day check shows a collision, who decides the response: renegotiating a deposit date, moving funds, or something else? - Will the templates be published for regional WordCamps, meetups, or do_action events? - What share of 2027 budget lines will carry due dates by the first variance check? ## 🔮 Future Research - Net cash forecasting that combines outflow due dates with expected income timing across events. - A currency policy for forecasts: fixed budget rates, periodic re-rating, or hedging, and how each affects variance reporting. - Whether minimum-contract integration (one shared summary interface) scales to dozens of regional WordCamps, or needs tooling inside WordCamp.org. - Volunteer burden measurement: how much finance process organizers accept before it affects retention. - Published event-finance practices from other open source conference organizers that budget in several currencies, for comparison. - The promised follow-up post after a full cycle: which parts failed, and why. ## 💡 Implications - **Practice:** a cross-team view can come from one standardized interface plus data the organization already records, without imposing a single tool on every team. - **Policy:** freezing the budget number at approval and checking at fixed intervals gives finance oversight defined moments instead of ad hoc contact. - **Security and privacy:** live links from volunteer-owned files into a finance rollup, plus a ledger importer, need access review; the read-only direction limits damage from rollup errors but not from exposure. - **Education:** first-edition teams such as WordCamp India 2027 get pre-tagged templates, which lowers the accounting knowledge a new team needs. - **Funding models:** account-name tagging and ledger-read actuals make budget-vs-actual reporting to sponsors cheaper to produce, if the organization chooses to publish it. ## 🧠 Learning Styles Assessment - **Reading level:** Flesch-Kincaid grade 7.7; Flesch reading ease 69.6 (computed on the stored article text: 920 words, 55 sentences, 16.7 words per sentence). #### 👀 Visual learners - Present: none. The post has no images, diagrams, tables, or screenshots. - Improve: show the cash calendar as a sample chart with three deposits colliding in one month; add a diagram of four event files feeding one rollup plus the ledger importer. #### 🔊 Aural learners - Present: no audio version. - Improve: a 3-minute recorded walkthrough of the rollup at a Community team meeting, posted with a transcript. #### 🗣️ Verbal learners - Present: plain first-person explanation; nine paragraphs open with bold lead-in phrases that name each point. - Improve: a short glossary for "rollup," "variance," "ledger," and "flagship." #### 🧩 Kinesthetic learners - Present: none; the templates aren't linked. - Improve: publish a sample template with dummy data so readers can add a due date and watch the calendar change. #### 🧠 Logical learners - Present: problem → cause → design → process structure; a four-step checkpoint list. - Improve: a table mapping each of the three gaps to the design element that closes it. #### 🧑‍🤝‍🧑 Social learners - Present: the author has asked all four teams for feedback and promises a public follow-up; the post accepts replies. - Improve: a discussion prompt for other event organizers to share how they handle multi-currency budgets. #### 🧘‍♀️ Solitary learners - Present: a self-contained narrative readable in about 4 minutes at 230 words per minute. - Improve: a checklist organizers can use to self-audit their own budget file against the summary-tab spec. #### 🌿 Naturalistic learners - Present: lifecycle framing: kickoff through month-after review. - Improve: tie the lifecycle to year-over-year learning, showing how one event's month-after review feeds the next event's template. ## 📊 Accessibility Assessment #### Screen reader semantics - Present: the page declares `lang="en-US"`; the post uses four H2 subsections and a real `<ul>` for the four checkpoints. - Improve: the nine bold lead-ins ("No view across events," "One budget file per event," and others) work as visual sub-headings but aren't headings, so screen reader users can't jump between them. Mark them as H3 (WCAG 1.3.1 Info and Relationships). #### Keyboard navigation - Present: the page includes a skip link. - Improve: not tested; focus order and visible focus on the share buttons and reply link need a manual keyboard pass (WCAG 2.4.3, 2.4.7). #### Contrast and readability - Present: short paragraphs; 16.7 words per sentence. - Improve: contrast wasn't measured in this analysis; check body text and link colors against 4.5:1 (WCAG 1.4.3). #### Text resizing and reflow - Present: text-only content with no tables or images, which reflows without horizontal scrolling risk from the body itself. - Improve: not tested at 200% zoom or 320px width; confirm the o2 theme sidebar doesn't overlap content (WCAG 1.4.4, 1.4.10). #### Media and captions - Present: no media in the post. - Improve: if a cash-calendar screenshot or walkthrough video is added, include alt text describing the collision it shows (WCAG 1.1.1) and captions (WCAG 1.2.2). #### Forms and interactions - Present: share links announce "(Opens in new window)." - Improve: in the templates themselves, don't signal a spike or missing due date with color alone (WCAG 1.4.1); add text markers. #### Standards reference - WCAG 2.2 AA gaps found: 1.3.1 (bold lead-ins as pseudo-headings). Untested and flagged: 1.4.3, 1.4.4, 1.4.10, 2.4.3, 2.4.7. Relevant to future additions: 1.1.1, 1.2.2, 1.4.1. ## 🌍 DEIB Assessment #### Cultural breadth - Present: four events across Europe, Asia, and North America, including a first edition in India; teams budget in their own currency and working style. - Improve: the aggregate view centers US dollars. That's a reporting choice, but saying why dollars are the base currency would help non-US teams understand it. #### Inclusive language - Present: gender-neutral throughout; organizers are described as the experts on their own events. - Improve: define "flagship," "rollup," "variance," and "ledger" for first-time organizers and translators. #### Neurodiversity support - Present: predictable structure (four H2 sections), bold lead-ins, short paragraphs, a four-item list for the process. - Improve: a one-line summary at the top of each section; real sub-headings for the lead-ins. #### Representation - Present: organizers are described as mostly volunteers doing negotiation work across timezones. - Improve: no organizer is named or quoted; a line from one of the four teams would show the process from their side. #### Psychological safety - Present: the author takes responsibility ("The part that didn’t work was my side of it"), states a preference for agreed check-ins over monitoring, expects version 1 to have problems, and commits to reporting what failed. - Improve: say how teams can raise concerns about the process itself, outside the scheduled checkpoints. ## ✅ Logical Validity #### Strong reasoning - **Causal (currency section):** a live rate changes the dollar total daily → consecutive reports can't reconcile → and the rate applied to a past payment isn't the rate paid. The mechanism is stated and checkable. - **Deductive (due dates):** the ledger records only paid or invoiced items → uninvoiced obligations can't appear in it → budget lines need due dates to show future cash. The premises hold, so the conclusion follows. - **Design justification:** minimal shared requirements follow from the stated constraint that most budget builders are volunteers. The design choices trace back to that constraint. - **Scope honesty:** the closing labels the system a first version and commits to reporting failures, which keeps the outcome claims from overreaching. #### Fallacies - No formal fallacies found. Two weaknesses: - **Oversimplified framing.** Location: "the problem wasn’t any of the spreadsheets." Weakness: two of the three gaps (inconsistent categories, inconsistent currency handling) were properties inside the files, not only between them. Fix: "each file worked for its team; the differences between files only broke the combined view." - **Outcome stated before evidence.** Location: "Now that shows up as a spike in a single row, months ahead of the invoices." Weakness: no full cycle has run, per the closing paragraph. Fix: "should now show up," or report the first collision the calendar catches. #### Tone of voice - First person, plain, self-accountable ("I was more reactive than proactive"), respectful of volunteers ("the last thing I want is to tell them how to build a budget"). British spellings ("categorised," "organising") on an en-US site. ## 🛡️ DARVO Analysis - Not applicable to this source — the post contains no accusation, dispute, or conflict. The author assigns the failure to their own role, which is the opposite of the deny or reverse patterns. ## 🎯 Conclusion - **Bottom line:** four flagship budgets now share one summary interface and one account vocabulary; the rollup reads actuals from the books and turns due dates into a cross-event cash calendar, while teams keep their own files and currencies. - **Next steps for readers:** - Organizers: add due dates to large obligations first; that's where the calendar pays off. - Anyone budgeting across currencies: pick a fixed rate for forecasts and take actuals at the booked rate. - Watch Make Community for the follow-up after the first full cycle, and ask which rate converts forecasts and where income timing appears. ## 🔄 Refactor Appendix — Bringing four flagship budgets into one view > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Live exchange rates break budget report reconciliation > [!quote] ID:rw_01m2ayhsaxmt9fqy76nh4gkg2p > the same event’s dollar total changes every day, so no report ever reconciles to the one before it. **Context & use**: - "Where the problem actually was" section, third gap (currency). - Applies to any multi-currency budget: forecasts need a fixed rate, actuals need the booked rate. **Tags**: #xref #share **Highlight**: [view highlight](https://read.readwise.io/read/01m2ayhsaxmt9fqy76nh4gkg2p) <!-- atomicity: 1 idea ✓ --> #### [H2] Due dates on budget lines expose cash collisions early > [!quote] ID:rw_01m2ayhw20pdn89xzey0nv0a7n > Now that shows up as a spike in a single row, months ahead of the invoices. **Context & use**: - "What I built" section, cash calendar paragraph. - One optional field turns four budgets into a forecast of cross-event outflow. **Tags**: #xref #articleseed **Highlight**: [view highlight](https://read.readwise.io/read/01m2ayhw20pdn89xzey0nv0a7n) <!-- atomicity: 1 idea ✓ --> #### [H3] Some cash risks exist only in the aggregate view > [!quote] ID:rw_01m2ayhzc5fy324ec05scczayc > That’s a cash problem that only exists at the top level **Context & use**: - "Where the problem actually was" section, first gap (no view across events). - Explains why no single event team could have caught the collision. **Tags**: #xref **Highlight**: [view highlight](https://read.readwise.io/read/01m2ayhzc5fy324ec05scczayc) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Coordination risk sits in the seam nobody owns **Claim** (one sentence, Courtney's voice): When autonomous teams draw on a shared resource, the risk sits in the unowned space between their work, not inside any one team's work. **Evidence pointer**: [[#H3]] > [!quote] ID:rw_01m2ayj4bnjt4xpr6zz5v5t253 > nobody owned the space between them. **Scope & conditions**: holds when each team's work is sound and the shared resource (cash, a release date, a venue) is finite; fails when the teams' own work is broken, and the post's own category and currency gaps show part of the problem sat inside the files. **Links**: - [[Conway's law]] — because extends (organizational boundaries predict where the gaps appear) - [[The WPOCC]] — because applies-in maintainer stipend and microgrant payout scheduling - [[WordPress release coordination]] — because applies-in cross-team release dependencies <!-- atomicity: 1 idea ✓ --> #### [P2] The smallest shared interface makes the best integration contract **Claim** (one sentence, Courtney's voice): Ask autonomous contributors to standardize only the interface that answers the aggregate question. **Evidence pointer**: [[#H2]] > [!quote] ID:rw_01m2ayj20te81acdgwaaxnz4wx > That one tab is the whole integration. **Scope & conditions**: holds when contributors are volunteers or teams with their own working styles; weakens when the aggregate questions change often, because each new question widens the shared interface. **Links**: - [[API contracts]] — because extends (a summary tab works as a stable public interface over private implementation) - [[Outpost pkiw-kind Micropub contract]] — because applies-in plugin-to-plugin integration <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Which rate converts forecasts to dollars in the rollup? The post argues against live rates but doesn't name the forecast rate — https://make.wordpress.org/community/2026/09/11/bringing-four-flagship-budgets-into-one-view/ #fleeting #inbox - [F2] Why do flagships run outside the WordCamp.org budget tool (`wordcamp-payments/includes/budget-tool.php`)? — https://github.com/WordPress/wordcamp.org #fleeting #inbox - [F3] The cash calendar is outflow-only; where does sponsor income timing show up? — same post #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Check Make Community for the budget-rollup follow-up after the first 2027 flagship's month-after review — Harmony Romo promised a post after a full cycle #things - [ ] Draft a Field Notes item on the "own the seam" budgeting pattern — newsletter candidate from make.wordpress.org/community #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Bringing Four Flagship Budgets Into One View.md|Bringing Four Flagship Budgets Into One View by Harmony Romo]] ## Highlights - **No view across events.** Each team could see its own payment schedule. Nobody could see three events with large venue deposits landing in the same three weeks. That’s a cash problem that only exists at the top level, and I wasn’t positioned in a way to notice it. ([View Highlight](https://read.readwise.io/read/01m2ayhzc5fy324ec05scczayc)) - Note: Some risks exist only in aggregate: no single event team can see a cash collision across events. - Tags: atom/literature/h2 - **Currency handled differently in each file.** Some used a fixed rate, some pulled a live market rate. A live rate sounds better but is worse: the same event’s dollar total changes every day, so no report ever reconciles to the one before it. And a rate that moves is the wrong rate for a payment made months ago. ([View Highlight](https://read.readwise.io/read/01m2ayhsaxmt9fqy76nh4gkg2p)) - Note: Live FX rates break report-to-report reconciliation and misstate past payments; the fix is reading the booked rate from the ledger. - Tags: atom/literature/h1 - **One budget file per event.** Each keeps its own line items, currency and working style. The only shared requirement is that every file has an identical summary tab in the same place. That one tab is the whole integration. ([View Highlight](https://read.readwise.io/read/01m2ayj20te81acdgwaaxnz4wx)) - Note: Minimum-contract integration: standardize one interface (the summary tab), leave everything behind it to each team. - Tags: atom/zettel/z1 - ***So each budget line now carries a due date alongside its amount***, and the rollup turns those into a cash calendar — expected outflow by month, all four events side by side. That’s the part I couldn’t do before. Each team could always see its own payment schedule; nobody could see three events with large deposits landing in the same three weeks. Now that shows up as a spike in a single row, months ahead of the invoices. ([View Highlight](https://read.readwise.io/read/01m2ayhw20pdn89xzey0nv0a7n)) - Note: One added field (due date) turns four budgets into a cross-event cash calendar that shows deposit collisions before any invoice exists. - Tags: atom/literature/h1 - Four teams were each doing perfectly sensible work in four separate spreadsheets, and the problem wasn’t any of the spreadsheets — it was that nobody owned the space between them. ([View Highlight](https://read.readwise.io/read/01m2ayj4bnjt4xpr6zz5v5t253)) - Note: Coordination failures live in unowned seams, not in the work units themselves. - Tags: atom/zettel/z1