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?

Not a good reason. What about people who don't use GitHub at all? Why are they excluding them then?

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.

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.

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)