LinearB Slack Application Updates
Frequently Asked Questions
Connect to Jira and set the board for your team
Set up your initial team
LinearB Trial Setup
Github server (on-prem) connection guide
BitBucket server (on-prem) connection guide
GitLab server (on-prem) connection guide
Connect Github with a personal access token
Set up release detection method
Jira (cloud) connection guide
Jira server (on-prem) connection guide
How to create a Clubhouse API token
Troubleshoot - Can't find my repositories after authorizing LinearB in Github
Connect LinearB to your Project Management Tool
How to - Create and manage teams
How do I connect and manage WorkerB Team Alerts?
How to - Invite new users
How to - Work with team dashboard
How to - Handle High Risk Work
How to - Handle Material Pull Request Merged w/o Review or Basic Review
How to - Handle Hanging Review Requests and Long Reviews
How to - Manage and Customize Notifications
How to - Re-authorize git integration
How to - Merge accounts
How to - Use Slack commands
How to - Understanding Releases
How to - Set Jira board per team
How do I set up WorkerB Personal Alerts and Commands?
How to - Re-authorize GitLab integration
What is Cycle Time for Software Developers?
Detecting high risk work
Lightning PRs action filter
Long Living PR Action Filter
Using the App
What is "Work Breakdown"?
Code Change Rate
PR Open Rate
Time to Merge
Issues Done / Story Points Done
Pull Request Size
WIP (Work In Progress)
Done in Iteration
Point in History
Carryover from Iteration
Pull Request Filters
Updated in Iteration
Lightning Pull Requests
Review Request Hanging
Long Living Pull Requests
Pull Request State
Merged Without Review
Merged in Iteration
High Interaction Pull Requests
Understanding Pulse View
Draft Pull Requests
Pulse naming conventions - Jira
Pulse naming conventions - Clubhouse
Ineffective code contribution
Projects active contributors
Metrics Community Benchmarks
Work Breakdown Terms
Understanding Code Changes
Quality Code Metrics Explained
Updated by Boaz Dremer
How to - Handle Material Pull Request Merged w/o Review or with Basic Review
Why Is It a Problem?
Even the best developer makes mistakes and misses things. After coding for a period of time and self testing most coders become partially "numb" to issues in the code they just wrote and tested. The review process, putting a fresh "set of eyes" on code someone else wrote many times reveals issues that were accidently missed or forgotten by the code owner. Many times thorough review processes leading to critical quality fixes.
This is why skipping this process for Pull Requests that contains "untrivial" number of changes increases significantly the chances of missing problems and potential bugs and in general adding quality risk to the code base.
How to Handle?
In order to reduce the quality risk level that is introduced by Pull Requests merged w/o review you can can do one of the following actions:
Revert Pull Request
Git provides method to revert pull requests and get the base branch back to the state before the merge was done. This will remove the quality risk from the base branch, and pending branch is still available, will allow to open a new pull request and have a proper review process before this code is merged again.
Retroactively Review Changes
Even though this code was merged, It is possible to look and review the changes made in this branch. If there are issues that were found and needs to be fixed it is possible to open a new branch for all modifications and fixes that are required from the retroactive review.
Educate you team about the risks of this practice
When you come across one of these practices it is important to discuss this with your team member and explain the risks.