5 ms·

As a maintainer for quite popular Go repo (20k+ stars) I find really annoyed by the amount of trivial PRs (started at start of 2022 or some time like that). Esp

As a maintainer for quite popular Go repo (20k+ stars) I find really annoyed by the amount of trivial PRs (started at start of 2022 or some time like that). Especially then some random dude starts to "improve" tests by checking errors etc and submit multiple different PRs where each PR "fixes" only one file. this crap makes my life harder as I do this stuff from my spare time. Doing comprehensive review takes me 30min to 1h sometime more couple of hours to provide alternatives with examples etc. I have not seen almost no rise of useful PRs that add features or fix bugs since that change in early 2022. Only rise of trivial nononse PRs.

maximilianroos 4y ago
As a maintainer for two less popular repos (3K & 5K stars), I'm very happy to get small PRs with incremental changes. Many of our large contributors have started this way. We have a robust test and linting suite on both, so we often don't need much human engagement for reviews — code looks reasonable, tests pass, smash "Merge". Out of interest — do you find they're not actually improving the code? Or it's just not worth the time to review it?
- toimtoimtoim 4y ago
  For example: In Go you have `x.Close()` / `err := x.Close()` that returns an error and if someone starts to check/assert those usages in tests which you have ignored in test code. I think they are pushing the limits. No - these do not add value. No new use-cases are being checked, no improvement to coverage etc. or typo check tests. I do not reject these PRs. I review these and merge but I feel annoyed. This non-sense started somewhere around start of 2022. Before that I rarely ever see PRs like that.
  - robswc 4y ago
    Could it be people using CoPilot trying to score brownie points? lol
  - maximilianroos 4y ago
    Them doing it and you getting annoyed sounds like a bad equilibrium! I'd echo the sibling comment re adding what is / isn't appreciated into a CONTRIBUTING.md. My guess is people are doing it to get their feet wet with the repo, being helpful on the margin, and would not do it if they thought it was unhelpful on the margin. Here's PRQL's: https://github.com/prql/prql/blob/main/CONTRIBUTING.md https://github.com/prql/prql/blob/main/CONTRIBUTING.md
- robswc 4y ago
  I don't maintain a repo of that size but I have to say this sounds more reasonable. I guess it totally depends on the project. I guess tons of PRs could be annoying _but_ if they are actually useful PRs, then it would be nice to have smaller, more manageable PRs, no?
cehrlich 4y ago
How many stars were you at when this began to happen? I maintain a repo with 8k stars and so far we've not gotten a single PR that felt like it was in bad faith - even with the hacktober fest tag.
aliqot 4y ago
A good idea is to create a file called CONTRIBUTING, and then inside put 5 of your top bullet points for what you expect form a PR. I thought it was dumb at first, but people actually used them to my surprise. Hope it works out for you! Also it helps if you don't tag your repos for the hackathon things.
ficklepickle 4y ago
I find a lot of typos in documentation and I never create a PR lest people think I am one of those people. They really do make things worse for everyone.
- userbinator 4y ago
  I think that's the sort of thing which should be tacked onto other, more substantial changes. "By the way, I also fixed a few typos in the documentation" is much better than making that your ONLY change.
  - maximilianroos 4y ago
    Again — disagree — the cost of reviewing diffs is superlinear in their size, with a tiny intercept of the manual steps of opening the PR and clicking "Merge". Maybe this is too extreme but I cannot remember seeing a PR too small, and I've merged thousands.
- maximilianroos 4y ago
  Honestly this is baffling to me — who doesn't appreciate PRs fixing typos? Does even the parent commenter agree with this, assuming they're actual typos? I both try and make these PRs, and appreciate others doing it! That's how things get better.
- JelteF 4y ago
  Honestly these are my favorite PRs to receive for my open source side projects. They are easy to review and approve. The smaller the PR the less time consuming it is for me to deal with them. Big PRs that add complex new features are also appreciated of course. But setting apart time to review them is often hard given other responsibilities that I have. And often I personally don't even need the feature that's being added.
- PedroBatista 4y ago
  This is insane. What makes things worse for everyone is little documentation cobbled together in 5min like the homework of a teen just before class. Your genius code is useless in isolation.

maximilianroos 4y ago

As a maintainer for two less popular repos (3K & 5K stars), I'm very happy to get small PRs with incremental changes. Many of our large contributors have started this way. We have a robust test and linting suite on both, so we often don't need much human engagement for reviews — code looks reasonable, tests pass, smash "Merge". Out of interest — do you find they're not actually improving the code? Or it's just not worth the time to review it?

toimtoimtoim 4y ago
For example: In Go you have `x.Close()` / `err := x.Close()` that returns an error and if someone starts to check/assert those usages in tests which you have ignored in test code. I think they are pushing the limits. No - these do not add value. No new use-cases are being checked, no improvement to coverage etc. or typo check tests. I do not reject these PRs. I review these and merge but I feel annoyed. This non-sense started somewhere around start of 2022. Before that I rarely ever see PRs like that.
- robswc 4y ago
  Could it be people using CoPilot trying to score brownie points? lol
- maximilianroos 4y ago
  Them doing it and you getting annoyed sounds like a bad equilibrium! I'd echo the sibling comment re adding what is / isn't appreciated into a CONTRIBUTING.md. My guess is people are doing it to get their feet wet with the repo, being helpful on the margin, and would not do it if they thought it was unhelpful on the margin. Here's PRQL's: https://github.com/prql/prql/blob/main/CONTRIBUTING.md https://github.com/prql/prql/blob/main/CONTRIBUTING.md
robswc 4y ago
I don't maintain a repo of that size but I have to say this sounds more reasonable. I guess it totally depends on the project. I guess tons of PRs could be annoying _but_ if they are actually useful PRs, then it would be nice to have smaller, more manageable PRs, no?

cehrlich 4y ago

How many stars were you at when this began to happen? I maintain a repo with 8k stars and so far we've not gotten a single PR that felt like it was in bad faith - even with the hacktober fest tag.

aliqot 4y ago

A good idea is to create a file called CONTRIBUTING, and then inside put 5 of your top bullet points for what you expect form a PR. I thought it was dumb at first, but people actually used them to my surprise. Hope it works out for you! Also it helps if you don't tag your repos for the hackathon things.

ficklepickle 4y ago

I find a lot of typos in documentation and I never create a PR lest people think I am one of those people. They really do make things worse for everyone.

userbinator 4y ago
I think that's the sort of thing which should be tacked onto other, more substantial changes. "By the way, I also fixed a few typos in the documentation" is much better than making that your ONLY change.
- maximilianroos 4y ago
  Again — disagree — the cost of reviewing diffs is superlinear in their size, with a tiny intercept of the manual steps of opening the PR and clicking "Merge". Maybe this is too extreme but I cannot remember seeing a PR too small, and I've merged thousands.
maximilianroos 4y ago
Honestly this is baffling to me — who doesn't appreciate PRs fixing typos? Does even the parent commenter agree with this, assuming they're actual typos? I both try and make these PRs, and appreciate others doing it! That's how things get better.
JelteF 4y ago
Honestly these are my favorite PRs to receive for my open source side projects. They are easy to review and approve. The smaller the PR the less time consuming it is for me to deal with them. Big PRs that add complex new features are also appreciated of course. But setting apart time to review them is often hard given other responsibilities that I have. And often I personally don't even need the feature that's being added.
PedroBatista 4y ago
This is insane. What makes things worse for everyone is little documentation cobbled together in 5min like the homework of a teen just before class. Your genius code is useless in isolation.