Dispatches¶

Out of Time

Using a GitHub Discussions-First Approach Intake for Maintainers

I still spend time re-routing #1234: a question filed as a bug, a feature pitch that should've been an Ideas thread, an install problem with no version in the body. Discussion category forms fix what shows up in the forum once someone lands there. This post is about policy and wiring: where contributors go first, and what happens when they open New issue anyway.

Some maintainers want questions, ideas, and suspected bugs in GitHub Discussions, triaged in public, with Issues opened only after the work is real. That takes five pieces: chooser routing, a reserved issue template, discussion forms (see How to Write Effective GitHub Discussion Templates for YAML and the Ideas and Community Help examples), CONTRIBUTING.md, and a pinned rules thread.

How to Write Effective GitHub Discussion Templates

I'm wiring up community intake for an upcoming open source project. Issue forms and a pull request template were the easy parts. Community discussions were what I hadn't nailed yet.

I wanted a public place for questions and early ideas without Issues turning into a pile of one-liners. I've set up GitHub Discussions on other repos before; this time I wanted the same structured intake issue forms already give you.

So I used discussion category forms: YAML on the same schema as issue templates, with required fields, defaults, and labels on create, tied to a category instead of an issue chooser. Questions stay in the forum. Work that needs a tracker still opens an issue.

If you've shipped issue templates before, the field types won't surprise you. What's different is the plumbing: .github/DISCUSSION_TEMPLATE/, one YAML file per category, and a filename that must match the category slug—not bug.yml copied from Issues.

Publishing Docker Images to GitHub Container Registry

GitHub Container Registry ("GHCR") is GitHub's OCI-compatible container registry at ghcr.io. If your source code, releases, issues, permissions, and automation already live in GitHub, publishing container images to GHCR keeps the distribution path close to the repository that produced the image.

In this post, we'll publish a Docker image two ways: first manually from a local terminal, then automatically from GitHub Actions whenever a GitHub Release is published. Along the way, we'll cover image naming, authentication, permissions, release-driven tags, OCI labels, and the small details that make GHCR feel predictable instead of mysterious.

GHCR differs from a generic public registry when your project is already GitHub-centered:

• Images can be associated with a repository.
• Repository permissions can be used for package access.
• GitHub Actions can publish with the built-in GITHUB_TOKEN.
• Images can be public or private.
• Tags, labels, and package metadata sit near the release and source history.
• The registry supports standard Docker and OCI tooling.

A Modern Python Workflow with Astral uv

Python packaging has needed a reset for years, and uv is the first tool in a long time that feels like a real one. It's fast, opinionated in the right places, and broad enough to replace an entire pile of Python tooling with a single binary that actually makes the day-to-day workflow simpler.

The official uv docs lead with the claim that it's 10-100x faster than pip, and that number doesn't feel like marketing fluff once you use it for real work. uv gets there by doing something the older Python toolchain never pulled together cleanly: it treats dependency resolution, environment management, Python installation, and tool execution as one system.

Backseat Dream

With a Quiet Hand

I hope death comes like a quiet hand lifting me from the backseat, half-asleep, carrying me to my bed, where, tucked beneath familiar blankets and with eyes closed, the gentle voices of those I love pass through a cracked door, holding me a moment longer in their warmth as I slip into rest.

That is still the gentlest image I know for leaving this world. Not terror. Not noise. Not some grand and blinding revelation. Just the old mercy of being too tired to walk on your own and trusting that someone strong and familiar will carry you the rest of the way.

My memories of safety began in the backseat of a car at night. The tires humming. A light waiting at the end of the drive. Low voices drifting from the front seat while I hovered at the edge of sleep. Sometimes waking just enough to know we were home, then feeling someone lifting me before I ever had to stand and drifting deeper into sleep.

One arm under my knees, one hand at my back, my head against a shoulder.

No understanding the house in the dark. Only trusting the arms carrying me through it.

I hope it comes that way. I hope I am tucked beneath something familiar. I hope the voices of those I love reach me through a cracked door for one moment longer. I hope the end feels less like being taken than being brought home.

If I am granted that kind of mercy, it will be enough.

A Kind of Tiredness That Gets Into Everything

The moment that finally made me admit it wasn't dramatic at all. Early morning in the home office, I was just sitting in my chair and I said it out loud.

"I'm exhausted. I'm burning out."

Nothing was actively wrong in that particular second. No alarm going off. No argument. No fresh bad news. Just the usual screen glow, a chair I've spent too many hours in, a few tabs open, and that strange hush that sometimes falls in the middle of an ordinary day when your mind stops long enough to catch up with your body.

And what I realized, sitting there, wasn't a feeling so much as a weight. The weight of every small unfinished thing. Every obligation with my name on it. Every text I hadn't answered yet, every errand still waiting, every decision still asking to be made, every part of life that needed some steady portion of me I wasn't sure I had available.

It was one of those moments where the boundaries disappear. Work was in it, yes, but so was the house, the calendar, the relationships, the noise, the constant low-grade management of being a person alive in the world. I remember sitting there and thinking, very plainly, this is heavier than I've been willing to say out loud.

How to Use GitHub Projects Effectively

Most engineering teams still plan work in one tool and ship it in another. Issues live in Jira or Trello, pull requests live in GitHub, and every status change requires a human to copy context across tabs. GitHub Projects removes much of that friction by keeping planning, issue tracking, and delivery close to the code.

Current GitHub Projects is the planning layer on top of issues and pull requests: custom fields, saved views, built-in automations, roadmaps, charts, and API access. It replaces Projects (classic), not the same product with a new coat of paint.

For teams that already live in GitHub, the value is straightforward:

• Less context switching between a tracker and the code host
• Fewer stale status updates because issue and pull request state can drive project state
• One place to plan cross-repository work without losing repository-level detail
• A workflow that works for a two-person open source project, an inner source program, or a larger engineering org

Keeping GitHub Repository Mirrors in Sync with GitHub Actions

Mirroring a Git repository sounds simple until you need it to stay current without thinking about it. A one-time copy is easy. The useful version is a mirror that keeps following upstream branches, tags, and rewritten history without becoming another chore on your list.

I use this pattern for repositories I want to preserve, test against, or keep available under my own GitHub namespace. A recent r/github threasd asked about mirroring a public repository into a private one; this is the workflow I use for that and similar cases.

The twist is that I don't put the sync workflow in each destination repository. I keep the automation in a standalone private repository that acts as a mirror controller.

Before getting to GitHub Actions, it helps to understand the manual Git operation the workflow is automating.

Why Mirror a Repository?

A mirror is useful when you want a repository to follow another repository as closely as possible. That is different from a normal fork, where you expect to create your own branches, open pull requests, and maintain local work.

I usually think about mirrors as infrastructure, not collaboration space. They are useful for:

• Keeping a personal copy of an upstream project
• Preserving access to a dependency you rely on
• Testing automation against a repository under your own namespace
• Keeping several upstream repositories available from one GitHub account or organization
• Avoiding a manual Sync fork habit for repositories that should simply track upstream

That last point is the practical one. If the destination is supposed to reflect upstream, humans should not be the scheduler.