I do this quite frequently, for microservices other teams own, or for documentation changes to tech pubs. We have separate repos for individual microservices, with only a scrum team or two having merge permissions for each. I want my own team to review thoroughly before I waste the time of the owning team.
The easiest way I have found is to fork the repo into my private profile, then do all my work from a branch on my fork. I do a pull request against
master on my fork first, then when that is approved, do a pull request against
master on the "official" repo.
The reason I started doing it this way is our team is somewhat of a trusted innovator, so other teams would often just merge anything we sent them without questioning it. Doing the first pull request in a separate repo meant they couldn't merge it prematurely just by clicking a button. The permissions and visibility on both repos are easily controlled.
You don't have to do this with personal forks, you could create repos for longer-lived larger groups if that works for your use case. Perhaps one repo for everything from a certain contractor company, for example.