PR Ettiquette : my pet likes, hates

it’s time to talk about Pull Requests (PRs). I enjoy PRs, as they can tell a story. Good formulated PRs leave the reader knowing what you did, why you did it and how.

Try not to look at them as a necessary evil, but as a fantastic opportunity for learning and collaboration. Here's how to make the most of them.

Why Pull Requests Matter

PRs are your way of saying, "Hey team, I want to propose some changes" They help:

• To Share Knowledge: Everyone gets to see and learn from each other's code.

• Collaborate: A PR is a proposal. Use it to Discuss and improve code together.

• Maintain Quality: Catch bugs and ensure consistency. 4 eyes are better than 2!

My Tips for Creating a Great Pull Request

1. Keep It Short and Sweet

   • Why: Smaller PRs are easier and faster to review. Aim for around 200 lines of code (LOC) or less. Keeping PRs within this range helps maintain review quality and efficiency.

   • How: Break down big tasks into smaller chunks. For example, instead of one massive PR for a new feature, split it into PRs for the backend logic, frontend interface, and tests.

2. Be Clear and Descriptive

   • Why: A good description helps reviewers understand your changes quickly.

   • How: Use a template like:

       **What:**
       Briefly explain what you've changed.
     
       **Why:**
       Explain why this change is needed.
     
       **How:**
       Describe how you've implemented the change.
     

3. Always Test Before You Push

   • Why: To ensure your changes work and don't break anything else.

   • How: Run your project's test suite and any new tests you've added. Mention the testing you've done in your PR description.

4. See PRs as Learning Opportunities

   • Why: PRs are a two-way street. Both authors and reviewers can learn from each other. Be open for criticism!

   • How: Be open to feedback, ask questions, and share your thought process. This fosters a collaborative learning environment.

Tips for Reviewing a Pull Request

1. Be Kind and Constructive

   • Why: Positive feedback encourages growth and maintains a friendly team atmosphere.

   • How: Highlight what’s good, suggest improvements, and explain your reasoning.

2. Review Promptly

   • Why: Timely reviews keep the project moving and show respect for your teammate's efforts. Don’t simply LGTM to get that review out quickly! Read and give honest feedback

   • How: Set aside regular times to review PRs and communicate if you're delayed.

3. Focus on the Big Picture

   • Why: It's easy to get lost in minor details and miss larger issues.

   • How: Ensure the code aligns with project goals and doesn't introduce new problems.

Common Pitfalls to Avoid

• Submitting Huge PRs (my pet hate nr. 1]

  • Issue: Large PRs are tough to review and can delay feedback.

  • Solution: Keep them small and focused. If a PR is getting too big, consider splitting it into smaller parts.

• Being Vague in Descriptions

  • Issue: Reviewers might not understand the purpose or context of your changes.

  • Solution: Provide clear, detailed descriptions and link to any relevant issues or discussions.

• Taking Feedback Personally

  • Issue: Code reviews are about the code, not you.

  • Solution: Embrace feedback as a chance to learn and improve.

Final Thoughts

Pull requests are more than just a code review tool; they're a platform for collaboration and learning. By keeping them concise, clear, and constructive, you not only improve the codebase but also grow as a developer. Happy Reviewing !

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/helping-others-review-your-changes

https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests