3 ms·

Well done! Looking at the first few PRs in the list, you can see things like: - Adding a word in a comment. - Adding config files to self-promote dev service

by pscanf 3y ago

Well done! Looking at the first few PRs in the list, you can see things like: - Adding a word in a comment. - Adding config files to self-promote dev services. - Switching from using var to let. - Changing well-established behaviours of core functions. - Removing semicolons. - ... I'm sure most of those were opened with good intentions of improving the library, but at some point for the maintainer they just become spam (or worse, a growing burden that makes you feel guiltier and guiltier for not giving it attention). Celebrities hire bodyguards and fly first class (or private) to avoid the constant stream of attention and keep sane. I wonder what measures could be taken by celebrity OSS projects.

EdwardDiego 3y ago
> Switching from using var to let. One particular GH user submitted multiple PRs doing only that. Across multiple JS projects... ...feels like GH profile padding.
- fmajid 3y ago
  Not so much padding the profile as making the github contribution graph more solidly green.
Null-Set 3y ago
There was a trend for a while for people to open trivial PRs against popular projects, I believe in an attempt to pad their resumes.
- kynetic 3y ago
  This is still a trend unfortunately.
- gochi 3y ago
  They can keep padding their resume if it means little fixes actually happen. Even typos and little translations, they affect the general reputability of the software. Sounds like a fair trade, especially as most hiring companies can just look at PRs and see what was actually changed very easily.
- brabarossa 3y ago
  It's called Hacktoberfest.
- agilob 3y ago
  Hacktoberfest is coming
JelteF 3y ago
Personally as an open source maintainer I like the typo/wording fixes/automated refactor PRs the most. There's almost no effort needed from my side to review them, so I almost always merge those very quickly. It's the PRs that implement huge are the ones that you take the most time reviewing/discussing, and thus those are the ones I put off looking closely at.
- EdwardDiego 3y ago
  The submitter creating multiple var -> let PRs (one PR per file...), was also doing this, including the one file per PR, in other projects, and would've broken some of their legacy IE(!) users. https://github.com/MithrilJS/mithril.js/pull/2880#pullrequestreview-1607584605 https://github.com/MithrilJS/mithril.js/pull/2880#pullreques... That's a particularly obnoxious bot. Didnt even follow their workflow... I suppose it depends on scale, and the team size. And Github issues are 80% support forums, 20% bugs, 5% of the bugs come with reproduction test cases, if you're lucky.
  - JelteF 3y ago
    Yeah, okay of course you can take it to far. But in the general case I would not want to discourage people from opening "trivial" PRs. Since those are the PRs that cost me the least time to manage, while still improving the project (even if it's by a small amount).

by pscanf 3y ago

EdwardDiego 3y ago

> Switching from using var to let. One particular GH user submitted multiple PRs doing only that. Across multiple JS projects... ...feels like GH profile padding.

fmajid 3y ago
Not so much padding the profile as making the github contribution graph more solidly green.

Null-Set 3y ago

There was a trend for a while for people to open trivial PRs against popular projects, I believe in an attempt to pad their resumes.

kynetic 3y ago
This is still a trend unfortunately.
gochi 3y ago
They can keep padding their resume if it means little fixes actually happen. Even typos and little translations, they affect the general reputability of the software. Sounds like a fair trade, especially as most hiring companies can just look at PRs and see what was actually changed very easily.
brabarossa 3y ago
It's called Hacktoberfest.
agilob 3y ago
Hacktoberfest is coming

JelteF 3y ago

Personally as an open source maintainer I like the typo/wording fixes/automated refactor PRs the most. There's almost no effort needed from my side to review them, so I almost always merge those very quickly. It's the PRs that implement huge are the ones that you take the most time reviewing/discussing, and thus those are the ones I put off looking closely at.

EdwardDiego 3y ago
The submitter creating multiple var -> let PRs (one PR per file...), was also doing this, including the one file per PR, in other projects, and would've broken some of their legacy IE(!) users. https://github.com/MithrilJS/mithril.js/pull/2880#pullrequestreview-1607584605 https://github.com/MithrilJS/mithril.js/pull/2880#pullreques... That's a particularly obnoxious bot. Didnt even follow their workflow... I suppose it depends on scale, and the team size. And Github issues are 80% support forums, 20% bugs, 5% of the bugs come with reproduction test cases, if you're lucky.
- JelteF 3y ago
  Yeah, okay of course you can take it to far. But in the general case I would not want to discourage people from opening "trivial" PRs. Since those are the PRs that cost me the least time to manage, while still improving the project (even if it's by a small amount).