Dev process improvements

[tmenier]

As part of a planned move to GitHub Actions for automating some of my processes, I'm taking a closer look at the processes themselves to see if there's room for improvements. I started by looking at a number of popular .NET open source projects to make sure I have a good handle on the latest best practices and where Flurl might differ currently. Here are some observations about those projects:

• Almost all repos live under an organization, not a user. Flurl is taken...dang. FlurlHttp? FlurlDev? FlurlOrg?
• Most have a very simple branching strategy: main and small number of feature branches. Smells like GitHub Flow. I'll consider dropping my dev branch and getting in the habit of creating feature branches for my own work.
• Most diverge from GitHub Flow in one regard: releases aren't "continuous". If they were, I'd expect to see a release for every merge to main. That probably makes more sense for hosted web apps than for libraries, so I don't think I'll change anything there.
• Most PRs tend to go fork/feature-branch -> main/main. (No need for most feature branches to live in the main repo.)
• Most don't use GH Projects. Am I getting much value out of it? Kanban is nice for tracking issue statuses but maybe there's a simpler way?
• I usually don't close issues until a fix is released, but it seems like a more common practice is to close them when the fix is committed/merged. (And how did I not know about auto-closing via commit comment??)

Once settled on any process changes, I'll want to add some new GH Actions workflows to automate them as much as possible.

[SeanKilleen]

Since you asked for feedback (and thanks for tagging me! happy to help) --

FlurlHttp? FlurlDev? FlurlOrg?

I like FlurlHttp or FlurlDev best myself.

I'll consider dropping my dev branch and getting in the habit of creating feature branches for my own work.

I think this ends up being a really nice format, especially because you can add annotations to commits / PR titles and then you can use GitHub to auto-generate release notes based on the changes. Makes for a nice workflow.

If they were, I'd expect to see a release for every merge to main. That probably makes more sense for hosted web apps than for libraries, so I don't think I'll change anything there.

If you're going to a main branch strategy, I feel like there's a nice flow of tagging releases with a version using GitHub's release functionality. You could also choose to build something like Minver into your process and do a pre-release publish for every commit to main that gets an auto-incremented version based on the commits since the last tag. Not necessary, but mentioning in case you're interested.

Most PRs tend to go fork/feature-branch -> main/main. (No need for most feature branches to live in the main repo.)

Yep, that tracks in my experience.

Am I getting much value out of it? Kanban is nice for tracking issue statuses but maybe there's a simpler way?

I see no problem with GH Projects. Whatever helps you manage your flow. The nice thing about them is you can build a roadmap for a certain version and it's transparent and tied to the actual work. The new projects was recently made GA and it's really nice, especially if you're moving to an org model.

it seems like a more common practice is to close them when the fix is committed/merged

I do think that's cleaner. Tagging an issue in the PR and then merging the PR will close the issue too, and it's another helpful way to think about release notes.