I don’t think most developers care about being seen as the sole creator. Personally, I’m always happy when Jumble gets a new contributor. What matters to me is the quality of the PR, it should align with the existing coding style, stay within scope, and avoid unrelated changes. If a PR takes more time to review, clean up, and refactor than it would take for me to implement the feature myself, then yes, raising an issue first is definitely the better approach. Another thing is that your idea might not align with the maintainer’s vision, so the better approach is to open an issue first, discuss the proposal, and then work on a PR once there’s agreement.

TLDR; I think every product's contribution model and maintainers require different standards and shouldn't be called out for not following the GitHub established flow of PRs. I don't accept PRs on Github. You can send me an email patch if you want. Barriers to entry for a project and a maintainer can be a good thing depending on their model. I don't want just anyone lobbing PRs at me. Especially if they don't work for me, nor have any obligation to maintain the work they contributed. That's all on me now. My product models already load a significant amount of responsibility (more than many others), in order to offer guarantees, specifically around stability and secure supply chains. That said, copyright attribution is also a complicated thing too. Some contributors working for other companies require releases and detailed attribution, which can make it even more difficult to maintain contributed code. Trust me I want more help, but oss contributors send patches and walk away, that's just how it is. It wasn't that long ago PRs didn't exist, and most OSS contributions were handled by email, in "private". And now maintainers are expected to feel shame because their decisions are now forced to be public and if they want to share their source code, they also have to subject themselves to this.