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.
We expect to continue adding new Code Reactions as time passes. As of January 2021, the Code Reactions available are shown here:
Various categories of Code Reactions that are available as of January 2021
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.
Exceptional bug squashing effort!
Glad you remembered this!
Hard work is appreciated
Good attention to security
Nice tech debt reduction
This code taught me something
Looking forward to watching what you do next with this code
Reminder to check up later
Favorite change of the month
Difficult to follow
Hard to see why necessary
Break up this dense code
Is this FUD?
Can you ensure a test exists for this?
Tech debt reduction request
Can we move this?
Nix magic number
Can we DRY this?
Difficult to adapt
Doesn't match convention
Can this be removed?
Reuse existing method
Looks like a bug?
This could become a problem
Performance concern: move to async
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. 😄
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.
When you choose a Code Reaction, we'll automatically populate the comment field with the initial text you can use for your accompanying comment:
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.
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.
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:
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.
Any commit or code line that receives a Code Reaction will be highlighted with the "star" icon in the Commit Activity Browser:
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.
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:
User has clicked to leave a new comment on a line
User has scrolled to the bottom of a commit or commit group, where there is a box to react to the work as a whole
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.