Infrastructure Roadmap

[jcklpe]

What this is

The roadmap for Infrastructure's post-Refactor 2026 work — Open Austin's durable technical spine: systems of record, access, shared tooling, GitHub/org infrastructure, and repeatable operations. This issue stays a hub: the three epics below hold the real work; this keeps the shape and the priorities.

The three epics

People Systems — the systems of record and structure about people: who is involved, how they are grouped, and the tooling that holds it. Central thrust is a lightweight volunteer management system (VRM). It is the substrate Engagement builds onboarding, stewardship, and recognition on; it does not own those human processes.
→ People Systems epic: VRM and people/org records #523

Runtime Systems — durable, organization-owned hosting, DNS, backend, and deployment patterns, so Product Teams do not depend on undocumented personal accounts. Landlord Mapper is the live pilot.
→ Runtime Systems epic: hosting, DNS, and deployment #505

Security Processes — a repeatable approach to access and permissions across our systems, plus safe credential management. Platform-agnostic and human-administered; default to open where possible, locked down where necessary.
→ Security Processes epic: access, permissions, and credentials #498

Now / Next / Later

First-pass ordering — refine freely.

Now

• Security: define the access and permissions matrix (#524) — the credential work depends on it.
• People: GitHub Teams housecleaning (#427) and docs housecleaning (#476, #512).
• Runtime: keep the Landlord Mapper backend pilot moving (#511).

Next

• Security: choose and implement credential management (#479) — start by defining our actual needs and the solution.
• People: design and build the VRM (#506).
• Runtime: Landlord Mapper domain transfer (#508); org-wide DNS policy (#509); org-wide hosting policy (#510).

Later

• Onboarding coordination (#488) across People + Security, with the public Slack join link (#504) folded in.
• People: contributor-profile cleanup + automation (#468, #497) — may shift depending on how the VRM shakes out.
• Single sign-on exploration, if/when account sprawl justifies it.
• The miscellany buckets, as they come up.

Onboarding is cross-cutting

Its human side is Engagement (Research and iterate volunteer onboarding #474), its onboarding automation is People, and its access provisioning is Security — with Create a repeatable onboarding and access-provisioning process #488 as the coordination node.

Miscellany

Loose items outside the epics; some are standing long-term buckets, not tasks to finish:

• Collate all the software we're using #405
• Seek out more free NPO access to software #396 — a standing bucket for ongoing conversations about free/discounted NPO software access, not a task to close.
• Automate Google forms for data research hub to github repo #499 — parked seed of a future cross-cutting "public intake form automation" theme.

Scope boundaries

Infrastructure owns durable systems, access, shared tooling, GitHub/org infrastructure, and repeatable technical operations.

Infrastructure does not automatically own every admin, communications, volunteer-management, or project-management task just because it touches a tool.

[jcklpe]

EDIT: this comment has been superseded by the August 5 reorganization

July 20 framing for the Infrastructure working session:

• People systems: volunteer records, onboarding, access, skills, and contribution history.
• Project systems: GitHub organization/repository hygiene, Product Team conventions, and issue workflows.
• Runtime systems: durable hosting, backend, database, and deployment patterns.

Infrastructure should support the technical spine rather than own every human relationship, Communications task, or miscellaneous administrative process.

Proposed meeting outcome: sort the starter backlog into now/next/later, identify owners and dependencies, and decide which work belongs in #506, #498, #488, #505, #510, and #511.

[jcklpe]

EDIT: this comment has been superseded by the August 5 reorganization
I'd add one more broad categories:

• Security processes (which overlaps some with People systems, Project systems, and a little bit with Runtime systems), relevant issues: Choose and implement an org credential management solution #479 Security Processes epic: access, permissions, and credentials #498 People systems included "access" but I feel like this is a sufficiently different technical distinction.