I sometimes do something similar, as it gives a chance for the CI to run more comprehensive tests on other platforms that's hooked up to the PR flow, and "reviewing" your own code can be pretty helpful.

You could easily have your CI keyed on tags or commits, reviewing my own code is very helpful but also so wasteful of time.

> have your CI keyed on tags or commits

I think I treat "PRs" on my own projects as pretty much the same as tags or commits - they require pretty much the same amount of documentation and description as a PR to a third party if they are meant to be meaningful to myself in a few years time, after all.

Depends how much CD you have.

I can see doing this, stepping away from the change for a bit, come back and read the PR from a fresh perspective and see if you can make sense of the change and if there are any errors.

Also, the “paper trail” of PRs is nice to have.

That's commits with extra steps.

I don't use pull requests because it seems higher ROI to just put that effort into crafting a good merge commit message.

Aside from that, you've more or less described my workflow for solo projects.

I'm guilty of this. I open PRs on my personal projects and then merge them in myself. Not for every commit of course, but for the big changes.

I just like to see the diffs on the github UI. <shrug>

Installing delta locally may ruin the GitHub UI for you

It's a mindset thing for some people I think, they have a "flow" and just continue using it. I sort of see it, but it's a time sink.

Personally if I'm working by myself absolutely not, commit straight to main or a feature branch, life is way too short.

Yes. Because writing code is so easy a bot can do it these days. sets the everything else that goes into writing code that wants to be captured, so following process is about how much you love future you, who has to come in three/five/ten/twenty years from now and figure out wtf you were thinking when you wrote this. Did I mean to use > instead of >= or was I just careless?