Updating a Modular City Website With GitHub Issues

Most city websites are managed through a content management system.

Someone logs into a CMS like WordPress, Drupal, or another vendor platform. They find the right page. They edit a form. They upload a PDF. They do some basic design within existing components. They click publish.

That model is familiar, but it has a lot of hidden cost. The content lives inside a system most people cannot see. The change history is limited. The approval process is often informal. And the website becomes one more place where public information is copied by hand.

For a Modular City site, I propose a different workflow:

A staff member opens a GitHub issue in plain language. An agent makes the website change. A reviewer approves the change. The site publishes from Git.

No CMS dashboard. No proprietary page editor. No mystery database.

Just files, issues, pull requests, review, and a public record of what changed, as a versioned, git diff.

The basic idea

A website is made out of files; mostly html or template language that render html.

Pages are files. Blog posts are files. Service listings are data files. Meeting records are data files. Department pages are generated from data files. Open data exports are generated from those same files.

Git is design to keep a versioned history of those files. GitHub gives the city a place to request, discuss, review, and approve changes.

The staff member does not need to know Git. They do not need to edit Markdown. They do not have to understand git branches.

Their job is to describe the change clearly; to communicate information effectively and provide effective services efficiently. The agent’s job is to make the file changes. The reviewer’s job is to assess whether the change is correct and an intended improvement.

That is the replacement for the CMS interaction.

The workflow

Here is the whole process.

1. Staff opens an issue

An issue is a request.

It can be as simple as:

Please update the Parks and Recreation office hours. The new hours are Monday through Friday, 9:00 AM to 5:00 PM. This should appear on the department page and the service catalog.

The issue should say:

• what needs to change
• where it should appear
• who requested it
• when it needs to go live
• what source confirms the change
• whether there is anything sensitive that should not be published

This is no longer complex technical work. This is normal office communication, written down in a place where it can be tracked.

2. The issue is assigned to an agent

The agent may be a coding agent, a site maintenance bot, or a human maintainer using an agent-assisted workflow.

The important point is that the agent works from the issue.

It reads the request, finds the right files, makes the edit, and opens a pull request.

For example:

• update _data/departments.json
• update _data/service_catalog.json
• add a new meeting record
• replace an old PDF link
• add a public notice
• fix a typo
• add a new service page

The staff member does not need to know which file holds the answer. The agent does.

3. The agent opens a pull request

A pull request is the proposed answer to the issue.

It shows exactly what changed.

If the old phone number was removed and a new phone number was added, the reviewer sees that. If a meeting date changed, the reviewer sees that. If a sentence was rewritten, the reviewer sees the old sentence and the new sentence side by side.

This is the part most CMS workflows do badly.

In a CMS, the edit often disappears into the database. In GitHub, the edit is visible as a diff.

The diff is the receipt.

4. A person reviews the change

The reviewer checks the pull request before it goes live.

They ask:

• Is the request complete?
• Is the information accurate?
• Is the wording plain enough?
• Did the agent update every place this data appears?
• Does the change avoid PII and protected information?
• Did the site build successfully?
• Did accessibility checks pass?

If something is wrong, the reviewer comments on the pull request. The agent fixes it.

This creates a cleaner approval process than many CMS setups. Nothing needs to be published just because someone had editor access.

5. The pull request is merged

When the reviewer approves the pull request, it is merged.

The site rebuilds. The change goes live. The issue can be closed.

Now the city has a complete record:

• the original request
• the discussion
• the exact file changes
• the reviewer approval
• the publish event

That is a better audit trail than a normal CMS edit screen.

What a good issue looks like

A city does not need a complicated form. It needs a simple pattern.

Here is a good starting issue template:

Title:
Update [page, service, meeting, department, notice, dataset]

What should change?
Describe the change in plain language.

Where should it appear?
List the page, service, department, or dataset if known.

What is the source?
Paste the approved text, source document, staff email, agenda item, ordinance, or public URL.

When should this go live?
Add a date or say "as soon as approved."

Is anything sensitive?
Note any PII, protected addresses, legal material, medical information, personnel information, or security-sensitive details that should not be published.

Who should review it?
Tag the responsible department or reviewer.

This is the new CMS form.

The difference is that the form creates work in public view, not a hidden database edit.

Common city website updates

Most website updates fit a few patterns.

Update a page

Example:

Replace the introduction on the Economic Development page with the approved paragraph from the attached memo.

The agent edits the page file. The reviewer checks the wording. The pull request is merged.

Update structured data

Example:

Change the business license fee from $75 to $90, effective August 1.

The agent updates the service record or fee schedule data. Every page and export that uses that data updates from the same source.

This is where a Modular City site is stronger than a normal CMS. The city is not just editing a web page. It is maintaining a reusable public record.

Add a meeting

Example:

Add the Planning Commission meeting for August 14 with the attached agenda.

The agent adds the meeting, agenda, agenda items, packet link, location, time, and public comment instructions.

The website page updates. The machine-readable meeting data updates. The open data catalog can point to the same record.

Add a public notice

Example:

Publish this notice of public hearing by Friday at noon.

The issue should include the approved notice text, publication date, hearing date, department, and reviewer.

The agent creates the post or notice record. The reviewer verifies the legal language before merge.

Fix a typo

Example:

Typo on the Utilities page: “recieve” should be “receive.”

Even tiny edits benefit from this workflow. They are fast, visible, and reversible.

How this replaces CMS roles

A CMS usually has roles like author, editor, publisher, and administrator.

The GitHub workflow has similar roles, but they are clearer.

Requester opens an issue. They describe what needs to happen.

Agent makes the file changes. It turns the request into a pull request.

Reviewer approves or rejects the change. They are responsible for accuracy.

Maintainer manages repository settings, templates, checks, permissions, and deployments.

Public user sees the published website and open data outputs.

The roles are not tied to a vendor dashboard. They are tied to a review process.

That matters. Cities do not just need content editing. They need accountable publishing.

What staff need to learn

Staff do not need to learn Git.

They need to learn how to write good requests.

That means:

• be specific
• include the approved source
• say where the change belongs
• identify the reviewer
• flag anything sensitive
• avoid pasting private information into a public issue

That last point is important.

If the repository is public, issues may be public too. A city can choose a private repository for working issues, or set up a public intake process that strips private information before an issue is created.

The rule is simple:

Do not put PII in the issue. Do not put PII in the website. Do not put PII in the open data export.

If a request involves personal information, the issue should describe the operational need without copying the protected details.

What the agent needs

The agent needs enough structure to do the job safely.

That usually means:

• clear issue templates
• labels like content, service, meeting, urgent, legal-review, and data
• a repository map that explains where pages and data files live
• automated build checks
• accessibility checks
• rules that prevent direct publishing without review
• examples of good past pull requests

The agent should not be treated as an unchecked publisher.

It is more like a very fast staff assistant. It drafts the change. A person still reviews the public record before it ships.

Why this is better than copying content into a CMS

The main advantage is not that GitHub is cheaper. It often is, but that is not the point.

The main advantage is that the website becomes a governed record system.

Every change has:

• a request
• a source
• a reviewer
• a diff
• a commit
• a deployment

The data is portable. The history is durable. The workflow is visible. The site can generate open data as a byproduct.

A traditional CMS asks, “Who can edit this page?”

This workflow asks, “What changed, why, from what source, and who approved it?”

That is the better question for public institutions.

What this does not solve

This does not remove the need for governance.

Someone still has to decide what is true. Someone still has to approve legal notices. Someone still has to protect sensitive information. Someone still has to maintain the service catalog.

The difference is that the work becomes visible.

Instead of hiding the process inside a CMS, the process becomes the system:

Issue. Agent. Pull request. Review. Merge. Publish.

That is plain enough for staff to use. It is structured enough for machines to help. And it gives the public institution a record it can actually steward.

This is the operating model I envisioned when creating Modular City.