Code Reactions allow code reviewers to accelerate the process of giving feedback while reviewing a commit or commit group. As of January 2021, there are about 40 Code Reactions available to code reviewers.

It is necessary for a Code Reaction to be accompanied by a code comment, but it isn't necessary for a code comment to be accompanied by a Code Reaction. This means that for teams (or developers) that don't want to use Code Reactions, they can still use GitClear's commenting system perfectly well without utilizing Code Reactions.

link🎭 Code Reactions available

We expect to continue adding new Code Reactions as time passes. As of January 2023, the Code Reactions available can be found upon clicking one of our five categories:

open_in_new

Five categories of Code Reactions that are available as of January 2023

In a typical pull request review process, it's rare for a developer to receive positive feedback, but we believe that words of encouragement can do much to promote desirable behavior. Also, it helps team cohesion and developer confidence to know that one's teammates or manager appreciates certain aspects of their work. When a developer knows that writing documentation, or removing tech debt, gets noticed and recorded, it increases the likelihood they'll do it again.

Following is a list of specific Code Reactions offered.

link👍 Appreciated

link🍿 Interesting

link🤔 Perplexing

link🔪 Removable

link🐞 Problematic

link🎁 Five benefits to using Code Reactions

There are several advantages a team can enjoy when they adopt GitClear's Code Reactions. We'll quickly review some of them below, so that if you are hoping to convince your team to adopt this system, you can link to this list to summarize the benefits, instead of explaining it yourself. 😄

link1. Teaches developers which types of feedback they might want to leave

It is our business' purpose to chat with teams and understand the types of feedback that they leave for each other. This means that we have much more incentive to discover and enumerate every type of feedback that a developer might want to leave.

If you have inexperienced developers on your team, this pre-defined set of reactions teaches teammates what type of feedback they might want to leave for their teammates. It also teaches them what type of feedback they can expect to receive themselves.

link2. Automatic comment wording suggestion saves time/energy

When you choose a Code Reaction, we'll automatically populate the comment field with the initial text you can use for your accompanying comment:

open_in_new

When you choose a Code Reaction, we automatically populate a comment suggestion

Especially when a code reviewer hopes to propose a suggested change, it can save a great deal of time and energy to prepopulate the pleasantries and jump straight in to the meat of what the reviewer would like to propose for consideration.

link3. Promotes positive feedback

Normal pull request reviews seldom include any encouragement or positive feedback. It's often seen as superfluous, and sometimes it's not clear what type of positive feedback could be left.

Using Code Reactions, the first two rows of possible reactions ("Appreciation" and "Interest") are dedicated to providing an opportunity for the reviewer to provide words of encouragement. This is the perfect chance to help committers know that their work is recognized and celebrated, which can in turn lead to better receptiveness to change suggestions. It also promotes a positive environment between developers, so there is reduced likelihood of interpersonal issues between members of a team.

link4. Identify patterns of feedback for meta improvement

When reviewing pull requests without GitClear, there is no continuity from PR-to-PR. This means that if a particular developer is prone to bad habits like not writing tests, that habit can perpetuate for months or years. Even if the developer is told "Please add tests" during every single PR they submit, it requires heroics from management (or the developer themselves) to prevent this same feedback from being delivered month after month. That is, the manager would have to personally read each PR from their team and take notes in order to recognize which types of feedback are being repeatedly given to a dev.

Code Reactions solve this by aggregating all of the reviewer sentiments as time passes. From the Highlights page, the manager can view a rollup of the Code Reactions that were received for a particular developer over a time range:

open_in_new

Highlights page shows which Code Reaction a developer has received, how often, and what comments accompanied the reactions

This view can also be used to ascertain if a particular developer is leaving the same reaction excessively. For example, if every pull request reviewed by Charlie receives the comment "Performance concern," the manager can be aware of this trend and judge whether Charlie's request is reasonable, and if so, how to ensure that the team abides the request without Charlie having to leave it on every single PR.

link5. Team-wide visibility to help developers always be learning

Any commit or code line that receives a Code Reaction will be highlighted with the "star" icon in the Commit Activity Browser:

open_in_new

Any commit that has received a Code Reaction is demarcated in the Commit Activity Browser

Since the Senior Developers on your team are unlikely to have the time to review each and every commit from the repo, these stars help spread the suggestions that your Senior Developers might offer so that the rest of the team might read & consider it as well. This is especially effective when positive feedback is left -- the positive feedback is spread throughout the team, offering the usual multitude of benefits that stem from public praise.

linkHow to use Code Reactions

No special steps are needed to utilize Code Reactions. When a user reads a commit or commit group in GitClear, we will automatically provide a Code Reaction UI form so long as the user is not reading their own code. The Code Reaction form is available in the following circumstances:

Code Reactions are not available in response to comments -- they are only provided when the user is commenting directly on code that is not their own. As mentioned above, a comment must accompany any Code Reaction, so that if a problem or change is suggested, the reviewer who makes the suggestion will be responsible for filling in the specific details of what they would like to see changed.

The default text for many Code Reactions is constructed specifically to induce additional details to be provided. For example, if a reviewer chooses the "Doesn't match convention" reaction, the default text populated in the comment box is This is an unorthodox solution. The more conventional way to accomplish this would be. This works to reduce scenarios where a reviewer makes a suggestion without taking the time to think through the implications of what they're suggesting.