Thank you @drumm!
With a very basic trial, I see two things.
1. Give commands we can copy/paste to pull the changes as a branch in the repo. I see you have already created an issue for this at #3155137: Add full Git commands for working with issue forks.
2. Clarify the reason and usage for "New branch".
Right now, this appears immediately once we click "Fork [project]". It kinda implies that we should click that to create a new branch. My first thought is why even have this option. In most cases, we have a patch build upon a previous patch, so a single branch should be enough. That said, there are some reasons for having multiple branches:
1. Rebasing, but even merging the main branch into the issue fork branch would give similar results.
2. Trying out an entirely different approach.
Now, the second point is not frequent but still a valid reason to have this functionality. I would suggest we could improve the UX around this to clarify how maintainers could use the feature. How about something like this?
1. When someone clicks "Fork [project]", a fork for the issue is created along with a separate branch. The branch name could be the same as the issue number. It could (optionally) be prefixed or suffixed with the issue branch so that the maintainer knows the target branch from the branch name.
2. The "New branch" option should still be there but in most cases, we never have to use it.
3. Give per-branch commands that the contributors can copy/paste to pull in changes for each of the branches.
Another thing I'm wondering: Do these issue forks get cleaned up once the issue is closed or at some other point?