| Things practical things that have helped me: - The idea of different types of comment. Suggestions vs questions vs more serious, “I think this might break X” - As a submitter, take the time to do screenshots if it is UI focused. Read through it once and if some bits require explanation then add your own comments. Basically due diligence - Be hyper aware of how language can escalate a situation. Ditch abrasive sentences. Re-write to be more questioning or helpful. - if it’s a naming problem, make suggestions. “I find the name X confusing because Y. How about something along the lines of A or B” - If it’s a larger problem, and you can meet face to face. Then do so. It will save a lot of back and forth. Or make a phone call. You’re there to make the cosebase better for everyone. Not a public flame war. - Agree as a team etiquette. Ideally codify it - Ask yourself the question: “Does this really matter?” Sometimes I don’t bother commenting because while I disagree, I realize that it’s a style thing and it doesn’t affect the codebase at large. Sometimes it’s also worth commenting anyway. That way there is a potential to steer things “your way” but no big deal if not. - Make positive comments. Try not to dish out praise. If you see something cool, a neat trick or a really elegant solution or even something you didn’t know, then it’s worth writing - It’s okay not to comment at all. If you can’t find fault. Then just green light. Too many people feel they have to find “something” - I find it useful to acknowledge when comments have been addressed. This can simply be “Done”. - The offer to pair on a solution to a problem can be effective I was going to put this and more into a blog post but have never got round to it |