🔥 BdgrovesBot — A Wildfire Bot That Edits Wikipedia at 7am

There's a particular kind of restlessness that comes with watching fire weather. QGIS open on one monitor, WFIGS on the other, an eye on the Red Flag warnings, and somewhere in the back of your mind you're already doing the math on fuel moisture and wind direction. Most people don't live this way. GIS analysts who also run Wikipedia bots absolutely do.

Today I finished something I've wanted to build for a while: a fully automated pipeline that watches for wildfires in Tuolumne County and updates Wikipedia without me touching a thing. It went from zero to live in a single day, and that's worth writing down.

The problem

I created two Wikipedia pages yesterday — 2026 Tuolumne County wildfires and Wildfires in Tuolumne County, California. The county I work in, the terrain I map, the fires I monitor. These pages needed to exist, and now they do.

But the moment I published them I saw the problem: keeping them current is manual labor. A fire breaks out at 3am, I wake up to a Twitter alert from my own bot (@SierraNevadaWX), and then I'm supposed to go hand-edit a Wikipedia table while half asleep? That's not a system. That's just being reactive. The fix was obvious: automate it.

The build

BdgrovesBot was already half-built. It was querying WFIGS — the National Interagency Fire Center's wildland fire geospatial API — and refreshing a GeoJSON layer for my QGIS fire-monitoring setup. The Wikipedia piece existed too, but it only updated acreages for fires already in the table. New fires still meant a manual row entry.

So today I rewrote the core logic to handle both cases:

The authentication rabbit hole

Getting Pywikibot to authenticate cleanly for automated runs took longer than it should have. My first test run prompted me for a password interactively — fine for local development, completely broken for a GitHub Actions runner at 7am when no human is watching.

The fix was a Wikipedia bot password through Special:BotPasswords, stored as a GitHub Secret, with the workflow writing a passwords.py file at runtime from that secret. The file never touches the repo. The password never appears in logs. The runner writes it, uses it, and it's gone.

The moment it worked — Page [[2026 Tuolumne County wildfires]] saved in the GitHub Actions log, with no password prompt — was genuinely satisfying. That's the whole pipeline: WFIGS → Python → Pywikibot → Wikipedia, headless, on a cron job, every morning.

The test insert

Before going live I needed to verify the write pipeline end-to-end, which meant actually writing to Wikipedia and confirming it landed. So I added a --test-insert flag that creates a clearly-labelled fake fire called "BdgrovesBot Test" and pushes it to the page.

It worked on the first try. The row appeared exactly as designed — name, coordinates stub, acreage cell, start date, notes stub, reference stub. I deleted it manually a few minutes later. The whole thing took about two minutes.

That test insert is the kind of thing you can't fake in a dry run. A dry run tells you the code runs. A live test insert tells you the auth works, the table parser works, the row builder works, and the Wikipedia API accepted the edit. All different things.

BRFA: doing it by the book

Here's the thing about Wikipedia bots: you're supposed to have approval before you run them. The process is a BRFA — Bot Request for Approval. You file a page, join a queue, get reviewed by a member of the Bot Approvals Group, run a supervised trial, then get full approval.

I filed today: Wikipedia:Bots/Requests for approval/BdgrovesBot. The task is non-controversial — data maintenance on pages I created, sourced from a federal government API, no prose editing, no cross-article changes. The dry-run log is attached. The live test insert is documented. The GitHub Actions logs confirm headless authentication.

Then I switched the workflow back to dry-run mode while the BRFA is pending. The bot still runs every morning at 7am. It still queries WFIGS. It still refreshes the QGIS GeoJSON. It just doesn't write to Wikipedia until BAG signs off. When that happens, one line in the workflow file flips it live.

The fire situation, while I built this

The whole time, I had an eye on the actual map. The Pocket Fire in Yavapai County, Arizona had reached 1,467 acres at zero containment — a Type 1 incident, the highest level, 969 personnel on scene, an estimated final cost pushing $20 million. A southeast wind event was forecast for the weekend, and the Tucson and Flagstaff NWS offices had Red Flag Warnings posted through Saturday night.

My QGIS project pulls the national active-fires layer and the NWS watches-and-warnings layer both live. I could watch the Red Flag polygon sitting right over Yavapai County while I worked — the Pocket Fire flanking, main behavior running along the sides of the perimeter. Not the most aggressive behavior, but with a wind event incoming and zero containment, it's the kind of thing you stay up watching.

Nothing active in California. Nothing in Tuolumne County. The TuCo monitoring setup was running and quiet — which, when you build tools like this, is the best possible update.

What comes next

BRFA review usually takes one to two weeks. If BAG approves a trial — probably 20 edits — I'll run it, post the results, and wait for full approval. After that the bot runs fully autonomously, no human in the loop between WFIGS and Wikipedia unless it flags something.

The longer-term vision is coverage. Nevada fires. California statewide. Maybe a sister page for every county that needs one. The framework is the same every time — WFIGS query, table parser, stub inserter, acreage updater. Honestly, the Wikipedia pages are the hard part. The code is the easy part.

For now: one county, one bot, one BRFA in the queue. The fire map is quiet. The workflow is live. The code is clean.

Going to go watch the Pocket Fire radar loop for a while.

Source at github.com/bdgroves/bdgrovesbot. Built in Tuolumne County territory — if you can see the smoke from your porch, the bot already knows.