It’s all in the approach: start with a “thank you for the project”, and a “hope you don’t mind but I’ve corrected a few typos” and nobody will shout you down. Only go with a blank PR description and it’ll come across as arrogant and spammy.

As a counterpoint, these kinds of formulaic ingratiating preambles turn me off. Get to the point of your PR, so I can judge on its merits!

completely agree, I'll take "fix typos" any day over three sentences that don't add anything of value

There are people hunting double spaces or typos in code? For what contributor credits?

As a maintainer of a few open source projects, yes it happens a lot.

I want to believe some people just want to send small patches to projects when they notice something (I tend to do the same for projects I use) but my impression is a lot of them do it so that it shows up as "contributions" on the GitHub profile which they can then add to their resume (or get some other kind of street cred).

At least typos are actual fixes, far more often you get complete spam (people copy-pasting the contents of PRs and issues from 5 years ago, sending bizzare pull requests with hundred of commits as a merge commit, leaving cryptic comments on 5 year old commits). The spam reporting process on GitHub is kind of annoying to go through, but I trudge through it every time we get one of these PRs. There was one year of Hacktoberfest where some streamer told people that if they just spammed projects with 5 PRs they would get a free shirt and every open source project was DoSed by hundreds of garbage PRs made by accounts created the same day.

Personally as a maintainer, if someone is fixing one typo in order to "get started" contributing to a project I would prefer that they go through and check for any other instances of typos in the project to make a more complete fix (or even better, add a CI job that runs codespell or similar spell checkers). That feels more like someone actually interested in fixing something about the project, as opposed to sending a one-line drive-by patch to pad their resume. (I'm still happy to take the patch of course!)

> Personally as a maintainer, if someone is fixing one typo in order to "get started" contributing to a project I would prefer that they go through and check for any other instances of typos in the project to make a more complete fix (or even better, add a CI job that runs codespell or similar spell checkers). That feels more like someone actually interested in fixing something about the project, as opposed to sending a one-line drive-by patch to pad their resume. (I'm still happy to take the patch of course!)

I have to disagree, changes to development processes are the worst kind of drive by contributions. I don't want CI jobs contributed from someone who isn't going to maintain them.

I mean, I would prefer that it be done as part of a discussion with upstream but if you're talking about a GitHub Action it's not really that much effort to maintain in my experience.

But even if adding CI jobs is not the preference of upstream, I would prefer that the contributor runs codespell locally and fixes all of the issues rather than just sending one-line patches. And I can imagine much worse forms of drive-by contributions than CI jobs that you can easily disable in the future.

I fix documentation typos or broken links because they really annoy me. There are some egregious examples of people doing it for GitHub-as-a-social-network reasons, but I think some are like me and just want to fix the writing.

I always start with a small patch to test the waters of a project. That way i dont waste my time with a larger patch if the project is a PITA to contribute to.

I similarly contribute only minor language and writing corrections to Wikipedia, and usually anonymously (unless my phone has randomly pulled a blocked IP and I need to sign in). I don’t consider myself enough of an expert in any Wiki-worthy topic to do anything more, but I’ll make damn sure small mistakes get addressed.

I feel even less qualified to contribute corrections on GitHub mostly for the same reasons mentioned above. Staying anonymous prevents anyone from thinking I’m attempting to capitalize on low hanging fruit.

Yes.

There’s also a couple of video tutorials that show how to make a pr, using node or nom on GitHub, and people just follow the tutorial verbatim, not thinking about what they’re actually doing.

oh boy... I am thinking of having it as an interview question - once someone raises a PR for an empty space it's an obvious NO )))))

Yes. I have a lot of long, boring stories about exactly this.

> and nobody will shout you down.

Unfortunately not my experience everywhere.

> Only go with a blank PR description and it’ll come across as arrogant and spammy.

Not at all what I was doing when I triggered the open source maintainers I was talking about.

> Rejecting useless or white space-only PRs is quick and easy.

No, it really is draining.

> I’ve gone through a few projects and updated the documentation as I explored the codebase. Reception ranges from thankful to people scorning me for attempting to make contributions that weren’t code changes. It’s frustrating when maintainers are more interested in keeping people out than in considering actual code or doc improvements.

It's frustrating when people make "contributions" that take more effort to review than they put in and then get mad when they don't get thanked for it. This attitude is exactly why dealing with drive by pull requests is not "quick and easy" - suddenly you need to do social and public relations stuff when all you want to do is code.