Section 1.1: Lack of Clear Reviewers or Titles

When you receive a PR without designated reviewers or assignees, tracking updates can become cumbersome. To avoid this confusion, always include the necessary reviewer and assignee details before submitting a PR.

For guidance on how to add reviewers and assignees to your PR, consult the official documentation. Additionally, ensure your PR title is descriptive enough to provide clarity in the Git history once merged. Avoid vague titles that may only make sense to you.

Section 1.2: Addressing Delayed Reviews

It's understandable that everyone has busy schedules. However, as a reviewer, it's crucial to recognize the assignee's need for timely feedback on their PR. In larger teams, it’s not uncommon for PRs to remain under review for excessive periods, sometimes days rather than hours. Establishing a Service Level Agreement (SLA) for PR reviews can help set clear expectations for all parties involved.

One effective tool is Slack Reminders, which allows you to set alerts for your PRs and receive timely reminders in your Slack channel. For more information on managing reminders, check the resources available.

Section 1.3: The Need for PR Templates

In today's remote work environment, communication often occurs asynchronously, which can lead to delays in PR reviews when information is lacking. If your PR doesn't contain sufficient details, expect at least a 24-hour delay in the review process.

A PR should include essential information such as:

• The module affected by the changes
• Background context on why and how the changes were made
• A linked JIRA ticket
• Testing instructions
• Any specific changes to the environment necessary for the review

To streamline this process, utilize PR templates that prompt developers to include these critical details before submission. A simple template can save significant time and reduce back-and-forth communication with the assignee.

Section 2.1: Repeated Mistakes in Reviews

New developers often fall into the trap of repeating previously addressed mistakes, making PR reviews frustrating. If you receive feedback on best practices or logic in a PR, make sure to avoid the same issues in future submissions.

Conversely, ignoring feedback from reviewers—especially after they’ve invested considerable time—can damage the collaborative spirit. It's essential to acknowledge their efforts; simple gestures like responding with a thumbs-up emoji or “Done” can foster better communication.

Section 2.2: Keeping PRs Focused

One key principle is to keep each PR limited to its intended purpose. Avoid cramming unrelated fixes into a single request. While addressing minor code smells may feel necessary, doing so can complicate the review process.

Limit your PR to about 400 lines of code to ensure efficiency. Some companies outright reject submissions exceeding this length, as research shows that reviewers become less effective after extended periods of reviewing large blocks of code.

Section 2.3: Mindful Communication

Maintain a respectful tone in your reviews and responses. Everyone is learning, and it’s vital to approach feedback constructively. Avoid using all caps, which can be perceived as shouting, and express gratitude to your reviewers for their contributions.