I prefer people open issues before sending in PRs. I also always open an issue before creating a PR. It's possible the maintainer has different ideas/context I'm not aware of. You just never know. Surprise PRs can be disappointing for both parties if the maintainer decides to turn them down.
My approach is mostly shaped by my company's culture (which is definitely not one-size-fits-all): if it's a quick thing to code up, I prefer submitting it as a PR with an [RFC] prefix (I've re-titled my PR to include that), so the maintainer knows I'm not too tied to it.
I'll probably lean towards opening issues before PR's in the future though - thanks!
The problem with one-line PRs is that Github forces you to fork the repo first, but I don't want to litter my repository list with forks for one-off contributions.
