> How is manually dispatched workflows different from just opening a PR to your own fork? I do that from time to time in order to run the CI before opening a PR against the CPython repo.

Here are a few thoughts on how it is different:
- They can be set up to take `inputs` that customize the behavior of the workflow run. Recently in another issue someone had asked about getting the Windows MSI installers from a CI build run but that workflow doesn't upload any artifacts; an input could be added that uploads the installers as artifacts in the cases they would useful while keeping the default behavior of not uploading artifacts for PRs, or an input could be added to enable additional debugging output/running extra tests to track down an issue
- Multiple builds of the same commit can be started; if there's a test that fails intermittently you could queue up 10 runs of a workflow and come back later to see if it is still happening from a larger sample size
- The jobs/workflows run can be more targeted; if you just want to build the docs part of a larger change set, you don't need to run the workflow for compiling + running tests. If all you care about is a generated installer, only that workflow needs to get run (less likely to hit the max concurrent builds for your account if you have workflows running in other non-cpython repositories)
- Temporary PRs don't need closing to keep subsequent commits from runnings jobs if you don't care about their results, or after the PR gets merged in the upstream CPython repo
- May be marginally faster to trigger a workflow run than opening a PR (in terms of slower loading pages/tabs on the GitHub website)