• Subscribe
    1. Discussions
    2. No offensive communication during Code Reviews

    No offensive communication during Code Reviews

    Weverton Timoteo
    3 replies
    Do you want to improve communication in your Pull/Merge Requests? - Stop commenting only offensive emoticons, such as 🤢, 🤮, 😵, 😱, 💩,🙈 - Start explaining why this is bad and how it can be harmful to the codebase - Stop commenting single ✂ or 🔫 - Start also making explicit what to remove from the code besides using emoticons - Stop asking to refactor without examples - Start using Suggestions to allow the author to visualize what are you purposing - Stop ignoring refactors and enhancements - Start by giving congratulations/appraisals to the author by doing that - Stop commenting in Pull Requests and don’t check if the author or other peer interacted with your comment - Start using Notifications page or configuring your email to receive when someone replies to you What else you would share?

    Replies

    Mansoor Osnar
    Hey Weverton! Thanks for sharing. These are great tips. Since it's PH, I can't help but mention that we built CodeSync to help improve the code review process and address development team mis-alignment. The idea is that you can see what your teammates have coded, before they've submitted a Pull Request. This way, there are no surprises - no more writing and testing a bunch of code only to find out that teammates disagree with an approach, and having to rewrite/retest. You can review your teammates' work every day (or even real-time). We've still got a long way to go with CodeSync -- things like merging codebases, Slack integration for example, but it is currently a functioning app. So, just felt like putting it out there. :)
    Share
    Weverton Timoteo
    SourceLevel
    SourceLevel
    Hello @mansoor_osnar, thanks for your insights! At first glance, I don't like the idea of creating this kind of “authority” before developers opening a Pull Request. For me, this is the purpose of opening Pull Request and if the developer wants to share a work before it's done, it is possible to create a `Draft` for it. Pull Requests are an extreme useful tool/workflow to use as documentation as well, centralizing the discussion and even generating issues or other PRs to address them. So creating this almost real-time review during work, sounds like a “block” during developer workflow, getting the opinions before the solution is being purposed. I love tools that promote enhancements during code reviews, but I don't like this approach where reviews happen before opening a Pull Request. I think that for issues like that, a great pair programming session would address discussions upon building the solution. Here is some content that I've written to make discussions better during Code Reviews, if you want to check it out: - https://sourcelevel.io/blog/10-i... - https://sourcelevel.io/blog/how-... Sure, I would give it a try to better understand the workflow that you're purposing, I'm certain that reviewing before opening PRs isn't the only feature Code Sync has to offer. Thanks for sharing! Also, I would invite you to give SourceLevel (https://sourcelevel.io) a try and share your insights!
    Share
    WorkHub
    Launching soon!
    Great suggestions. We are not using them, but We will try. Thank you for sharing!
    Share