As an open source maintainer I used to have the impulse of asking for tiny changes before merging such as what this post is suggesting. The alternative is just accepting the change and immediately "fixing" it for you.
The main reason I did this was to give contributors "credit" for their work. I wanted brilliant the lines of code you be attributed to you, not to me who accepted your PR but added a semicolon to the end to make it consistent with the coding style. But it seems people don't mind the core maintainers being janitors for them, and if they continue to contribute, following by example seems to work be better than being asked to on their first PR.
The "cost" of this is delay, but more importantly I believe it dampens the intrinsic rewards that go with contributing to open source through Pull Requests. Specifically a chore component is introduced and depending on communications you may also feel reprimanded for opening an unpolished PR in the first place.
What Danger does seem to do well is softening this communication portion for required steps. I believe the list is short (sign CLA, pass CI comes to mind) but I would caution and discourage other maintainers from using Danger to enforce an arbitrary rite of passage.
Writing code that meets code-style expectations isn't just arbitrary, though - it's exactly what your brilliant contributor will need to get in the habit of, if he/she wants to become a brilliant maintainer in the future. As you mentioned, the form of communications matters here: A friendly bot that describes where linting failed and what needs to be done to pass CI, plus a brief "Thanks, this feature looks really interesting! Once it passes Danger I'm happy to merge!" from the maintainer will do the trick. There's no need for the core maintainer to be a janitor at all, just an encouraging voice. And that's what we love about open source in the first place, right?
Sometimes I interactively rebase the contributed PR commits to be exactly as I believe they should be while keeping the original author. This way when the same person open a new PR will be able to guess the required changes.
I've been really happy with the community work that's gone into the JS version of Danger.
The JS community jumps on new tools so quickly, and is really active in adapting and forming the shape of a project. I think this is one of my favorite parts of the JS community.
In case you'd like a service that provides similar functionality via a yaml file, I highly recommend var.ci: https://var.ci/
I've used it on a few OSS projects - the CakePHP/CakePHP project being the big one - as well as some private repos. Pretty powerful, and you can use it to automate away quite a few maintenance tasks on larger projects.
The main reason I did this was to give contributors "credit" for their work. I wanted brilliant the lines of code you be attributed to you, not to me who accepted your PR but added a semicolon to the end to make it consistent with the coding style. But it seems people don't mind the core maintainers being janitors for them, and if they continue to contribute, following by example seems to work be better than being asked to on their first PR.
The "cost" of this is delay, but more importantly I believe it dampens the intrinsic rewards that go with contributing to open source through Pull Requests. Specifically a chore component is introduced and depending on communications you may also feel reprimanded for opening an unpolished PR in the first place.
What Danger does seem to do well is softening this communication portion for required steps. I believe the list is short (sign CLA, pass CI comes to mind) but I would caution and discourage other maintainers from using Danger to enforce an arbitrary rite of passage.