Usually, for github, workflow is to have one fork (I even doubt you can fork the same repo more than once under the same account) but seperate branches per PR. Example:
- create fork, clone locally
- checkout a new, aptly named branch, say 'issuexxx-fix'
- commit/push some work
- create PR
When some time later you want to work on another issue you first get your fork up to date and repeat the above, in a different branch:
- checkout master branch again
- reset (or merge) master branch to upstream's latest commit
- checkout a new, aptly named branch, e.g. issuexxx-fix
- commit/push some work
- create PR
And suppose you'd need more work on an issue you worked on before already, you'll normally want to rebase the original and new work on top of the latest upstream merges as that might reduce the amount of work the maintainer has to merge it (you fix possible conflicts instead of having them do it):
- checkout the branch used
- rebase on latest upstream commit
- commit/push
- existing PR gets updated automatically