It never ceases to amaze me how many people will emerge out of the woodwork to earn a free T-Shirt each October! As someone who runs a moderate sized open source project that has merged over 900 pull requests, I always see a big increase in activity in October due to Hacktoberfest. This is a great thing, and I do appreciate each pull request! I personally review each one, which takes time. There are a few things that contributors can be mindful of that will make it easier on project maintainers getting a lot of PRs this month.

Minimize the number of changes you make at once

I'd much rather see you submit 5 smaller pull requests, than to try and do 5 unrelated fixes in one. Bonus, you just earned a t-shirt!

Be mindful of the diff

The first thing I look at in a pull request is the diff of files changed, I might even do this before reading a big description. So a pull request that makes significant changes, or has a long diff is going to take me a lot longer to review.

I'm not sure if all maintainers read through the diffs, but I would imagine that most do.

If a test fails, look into it

If one of the tests is failing (you will see a red x, and build failed, instead of a green checkmark if the project has automated testing setup) look into why. Your PR may be ignored or closed on some projects, on others the maintainer might have to look into why it failed.

Recently someone submitted a PR which failed, they looked into the build logs and were able to determine that it failed due because a network service was temporarily down. This helpful person told me to try re-running the test in the comments. This saved me from looking into it myself!

Separate Reformatting into its own PR

Generally speaking you should follow the code formatting guidelines or processes that are already in place. Some projects may not want you to reformat the code. But in some projects a good PR is to simply improve the formatting. If you do this, you should do it in its own PR. The main advantage to separating it out for me is that the diff will be huge when you reformat something, so it is a lot easier to just look at the formatting changes. If you have a logic change mixed in with a formatting change it is difficult to review.

Write Concise Meaningful Descriptions

It is really useful to summarize what you changed and why. At the same time you don't want to follow the recipe of those cooking websites that tell an elaborate story before actually getting to the ingredients.

To summarize, the maintainer is probably very busy so anything you can do to make their job easier will look good on you.