◈ veda / catalog NASA VEDA Contribute →
← All entries
Web app

DSE Hub

Tabbed hub for the Data Services & Enablement group: a timezone-aware meeting tracker (list / calendar / categories) and a PI roadmap, edited through an in-app changes cart.

Open the app ↗ View source ↗ by NASA VEDA · added 2026-08-19
#meetings#timezone#pi-roadmap#uswds#react#recurrence

◎ What it solves

Puts the group's meetings and PI schedule in one place, in your timezone, laid against the sprint calendar — and lets anyone correct it without a login or a backend.

⚠ Limitations & Risks

Every catalog entry must acknowledge at least one limitation or risk.

What it solves

“When is that meeting, and is it in this sprint?” is a question with no single place to look. The answer is spread across calendar invites you may not be on, a doc someone updated once, and whatever was said in chat — and each of those states a time in somebody’s timezone, rarely yours. A recurring meeting described as “every second sprint week” can’t be resolved at all without knowing the sprint calendar, which lives somewhere else again.

Three things fix that here. Meetings and PIs are one set of data, so there is a single place to look. Recurrence rules are resolved against the actual sprint calendar, so “every second sprint week” becomes real dates rather than an instruction you have to apply yourself. And every time passes through a view-timezone picker, so the schedule is rendered in yours instead of the author’s.

The fourth problem is keeping it current. A hub nobody can edit rots, but a login and a backend are more than this needs — so edits stage in an in-app Changes cart and open a single prefilled PR. No account, no server, and because every change file gets a unique name, two people editing at once cannot conflict.

Meetings scattered across sources and timezones, versus one resolved schedule

Before: meeting times live in calendar invites, a stale document and chat, each in a different timezone, with no way to tell which sprint they fall in. After: one dataset, recurrence resolved against the sprint calendar, rendered in the viewer’s chosen timezone, corrected by pull request.

BEFORE — three sources, three timezones📅 invites10:00 ET📄 a doc15:00 UTC💬 chat“after standup”“every second sprint week”…which weeks are those?⚠ no single place to look⚠ never in your timezone⚠ stale, and awkward to correctAFTER — one schedule, your clockmeetings + pis .jsonrecurrence → real datessprint 26.4 · week 2shown in your timezone🌐 view tz ▾🛒 changes cart → one prefilled PRno login, no backend, no edit conflicts

Recurrence is resolved against the real sprint calendar rather than left as an instruction, and the view-timezone picker means the schedule is rendered in the reader’s clock rather than the author’s. Corrections arrive as pull requests, so the hub stays editable without a server.

What it does

A tabbed hub (header tabs plus subtabs) with two areas:

Recurrence is real: weekly / monthly / sprint / sprint-week / TBD rules resolve to actual dates against the sprint calendar. Every time is timezone-aware — each meeting carries its own schedule.tz and a global view-tz picker in the header converts everything, remembered in localStorage.

Where the data comes from

Hand-curated data/meetings.json and data/pis.json, bundled at build time via import.meta.glob. There is no runtime fetch.

Edits (meetings and PIs) stage in an in-app Changes cart and then open a single prefilled new-file PR creating dse-hub/data/changes/<ts>.json. The loaders merge those change files over the canonical arrays at load — upsert by id, newest ts wins — which makes the flow token-free and conflict-free, since every filename is unique. On merge, dse-hub-compact.yml folds the change files back into the canonical arrays.

Run it locally

cd dse-hub
npm install
npm run dev