Wow I love the idea, thanks for making this and congrats on the launch.
From the comments I read I can tell the receiving devs can easily become grumpy if things are not as they want to the semi-colon.
A few ideas to solve that problem.
1. Have an internal team of experienced devs who make CRs and onboard the team of juniors on a new projects. From my experience, after a couple mistakes or misfit code, juniors adapt themselves, learn and end-up doing perfectly well.
2. When you submit a PR, submit a process with it (in a readme of some sort) with instructions on how the receiving devs should proceed with the PR. If they are not happy with it, maybe they can just say "not happy with it" and you take on yourself to figure out why. That sort of instructions. The last thing you want is them complaining they spend more time on it than simply coding it.
Im pretty sure the management of the human interface here is key because the only way this can work is if you've got off-the-charts feedbacks. You need processes for that (you probably do already).
From the comments I read I can tell the receiving devs can easily become grumpy if things are not as they want to the semi-colon.
A few ideas to solve that problem.
1. Have an internal team of experienced devs who make CRs and onboard the team of juniors on a new projects. From my experience, after a couple mistakes or misfit code, juniors adapt themselves, learn and end-up doing perfectly well.
2. When you submit a PR, submit a process with it (in a readme of some sort) with instructions on how the receiving devs should proceed with the PR. If they are not happy with it, maybe they can just say "not happy with it" and you take on yourself to figure out why. That sort of instructions. The last thing you want is them complaining they spend more time on it than simply coding it.
Im pretty sure the management of the human interface here is key because the only way this can work is if you've got off-the-charts feedbacks. You need processes for that (you probably do already).