I frequently perceive a sense of entitlement from drive by PR contributors, as if they are giving a gift to the maintainer, when in reality, it often takes more time for the maintainer to test, review, and give feedback on contributions than if they’d done it themselves.
I imagine the people spamming repositories for a T-shirt are the same people who will harass maintainers to “just merge it already.”
This is one reason why I generally open an issue first. Lets talk about my problem first. Maybe I add a PR / branch / patch as a PoC. Maybe it gets closed with "No" a few month later.
However, I don't see how that works with a hackaton mindset.
>I frequently perceive a sense of entitlement from drive by PR contributors, as if they are giving a gift to the maintainer, when in reality, it often takes more time for the maintainer to test, review, and give feedback on contributions than if they’d done it themselves.
If that's what you think then why accept pull requests at all on your project?
They probably should validate a somewhat matching commit with the same e-mail address ending up in a branch or something. Few if any projects modify those.
Just a piece of anecdata in regards to this, last year in my first Hacktoberfest I made a PR for an open issue on a project that got no response from the maintainer until a week later, where he said something along the lines of "Oh sorry, I missed this one, I'll get to it soon", and then he just never reviewed it or anything else on the project ever again.
Most of the PRs I make outside of work and personal projects are to obscure libraries I found useful, which usually have a maintainer whom awakens from their slumber once every few lunar cycles.
(I maintain a handful of small libraries that meet your description, and only recently "awakened from slumber" to release a new version of https://github.com/hunterloftis/throng after five years)
I'd take that a step further and require that the PR fixes an existing issue opened by a different user. Go ahead and fix a typo too if you want, but that alone won't get you a t-shirt.
Merging a PR requires effort from the maintainer.
I frequently perceive a sense of entitlement from drive by PR contributors, as if they are giving a gift to the maintainer, when in reality, it often takes more time for the maintainer to test, review, and give feedback on contributions than if they’d done it themselves.
I imagine the people spamming repositories for a T-shirt are the same people who will harass maintainers to “just merge it already.”
I don’t see conflict with this requirement. Maintainers should not feel pressure to speed through or acceptance.
This means not all os projects are likely to yield you a t-shirt, but it does mean your contributions must be good and relevant to have a chance.
There is some technique to reviewing a project and knowing what is likely to be pulled based on its context.
That aught to cut down on it.
Fwiw, DO should be doing something for the projects that accept a PR from this “fest” either t-shirts or a donation to a foss advocacy org or similar.
This is one reason why I generally open an issue first. Lets talk about my problem first. Maybe I add a PR / branch / patch as a PoC. Maybe it gets closed with "No" a few month later.
However, I don't see how that works with a hackaton mindset.
>I frequently perceive a sense of entitlement from drive by PR contributors, as if they are giving a gift to the maintainer, when in reality, it often takes more time for the maintainer to test, review, and give feedback on contributions than if they’d done it themselves.
If that's what you think then why accept pull requests at all on your project?
Well for one, last time I checked GH doesn’t allow this in their UI.
And on balance, I love open source!
It’s just one of those unfortunate things where it’s hard and slow to be considerate while being easy and cheap to be inconsiderate.
They claim they don't want to exclude projects that don't merge through the PR feature: https://twitter.com/MattIPv4/status/1311388583136301059
They probably should validate a somewhat matching commit with the same e-mail address ending up in a branch or something. Few if any projects modify those.
Not a good reason. What about people who don't use GitHub at all? Why are they excluding them then?
All projects _not_ using GitHub are already excluded.
1 reply →
Is there a logical fallacy where you appeal to only the rarest of circumstances? You want your t-shirt? Find some repo that uses PRs normally.
I'd love to know the name of it if there is! It seems to happen quite a bit.
Just a piece of anecdata in regards to this, last year in my first Hacktoberfest I made a PR for an open issue on a project that got no response from the maintainer until a week later, where he said something along the lines of "Oh sorry, I missed this one, I'll get to it soon", and then he just never reviewed it or anything else on the project ever again.
That's a perfectly normal Github experience, so it wouldn't invalidate the metric.
Do more than the bare minimum for your tee then. Hedge your bets.
Most of the PRs I make outside of work and personal projects are to obscure libraries I found useful, which usually have a maintainer whom awakens from their slumber once every few lunar cycles.
Ha! Thanks for the actually out-loud laugh.
(I maintain a handful of small libraries that meet your description, and only recently "awakened from slumber" to release a new version of https://github.com/hunterloftis/throng after five years)
I'd take that a step further and require that the PR fixes an existing issue opened by a different user. Go ahead and fix a typo too if you want, but that alone won't get you a t-shirt.
This seems like an eminently sensible suggestion and I'm perplexed as to why Digital Ocean wouldn't already have chosen to implement it.
I have a feeling there would be some problems with people submitting valid and helpful PRs but they aren't merged in time to be counted.
Ding ding ding, we have a winner. ;-)