# PR Feedback Given

![A stylized line graph shows time to merge is high at 18 hours but is trending up.](https://cdn.prod.website-files.com/610c8a14b4df1ae46b1a13a3/634800ee6be9560009ae8ec5_PR%20Feedback%20Given.jpg)

**What it is:** The number of comments written on PRs.

**Why it matters:** This visualizes who is giving the most support, since PR reviews and comments are a way to share knowledge and to encourage growth and learning opportunities.**‍** Giving feedback on PRs can be an example of glue work, the somewhat-invisible work that people do to lift up others on the team; our goal is to make this work more visible and valued on teams.

**How we calculate it:** The **total number of comments written on PRs**, including comments on one's own PR. We include comments on your own PR because they are often in response to a reviewer question, so these can also contribute to learning and knowledge-sharing on the team.

{% hint style="success" %}
**What good looks like**

While written communication styles differ between individuals, if a team that does their code reviews on GitHub, then 10 comments per person is a good benchmark to hit. This is based on research from our own data, looking across 6 person-weeks of data for 10 randomly sampled orgs in the Multitudes dataset.
{% endhint %}

{% hint style="info" %}
The trends we expect will vary by level. Senior engineers are expected to give more feedback than juniors, to share their knowledge across the team. However, juniors have a lot to offer in code reviews too, via a fresh perspective and clarifying questions (more here about [why it’s important to include juniors in code reviews](https://shortcut.com/blog/why-you-should-always-involve-junior-developer-in-code-review)).

That’s why we still recommend teams aim for more balanced participation across the team – it’s always good to make sure that your juniors feel comfortable speaking their mind and asking questions during code review.
{% endhint %}