3 ms·
People won't do any more work than they have to. If you need the PR to be backported, don't ask a question. Say "step 5. Backport this PR" Don't offer an easy o
by HeyLaughingBoy 4y ago
People won't do any more work than they have to. If you need the PR to be backported, don't ask a question. Say "step 5. Backport this PR" Don't offer an easy out.
Then if they don't you can ding them for not following the process. You can fix problems with process, but all that does is set a minimum floor of quality, it doesn't guarantee anything higher than that.
In your example, I'd have standards for coding practices, and reviews to be sure that they're met, and merges aren't allowed unless the reviewers all approve.
- avmich 4y agoThe first thing I write in a coding guideline, "This is a set of suggestions, not hard and fast rules." So in practice it's harder to figure out if the code is good enough from this standpoint. What is working, I think, is to have everybody agreed about 1) what actually needs to be done - a good understanding of details of the project - and 2) how it needs to be done - on high level, and on the low level some variations shouldn't matter too much.
- HeyLaughingBoy 4y agoI prefer a coding standards document that is divided up into hard and fast rules and guidelines and clearly states which is which. Otherwise, reviews can quickly degrade into arguments.
- avmich 4y agoCan you give an example of hard and fast rule regarding coding standards? I'd assume people who learned programming by books - and even those who learned otherwise - wouldn't name variables after rock stars, but something not too obvious?
- HeyLaughingBoy 4y agoSure. In the codebase for an 8-bit embedded system: recursion is forbidden.
- avmich 4y agoAh :) even tail recursion?