I suspect major code review cover up in my team.
Too many code reviews are merged without any comment.
Seems to me like there's no such thing as a code review without a single comment.
How can I as a team lead properly monitor that my team is doing a proper code review process and how can I help them to maximize the process' benefits?
Update
Thought people might want to know about any update. I tried a lot of suggestions that were given here. most were already in use.
some helped a bit.
However, the problem remained – some people continuously got bad code in when I was not looking.
I found that code review monitoring is not as helpful as giving my team tools to make their code better to begin with.
So I added a library named "jscpd" to detect copy pastes.
The build failed on copy pastes.
That eliminated one problem immediately.
next we are going to try codeclimate.
I am also doing a manual review on old code reviews once a sprint for half a day.
I am converting todos into issues/tickets – as I found out people are writing them, but they are never handled at a later point.
I am also doing meetings with the entire teams to review code when it is appropriate.
in general it feels like we are moving in the right direction.
Best Answer
I'm going to offer a different take from my fellow answerers. They are right - be involved if you want to see how things go. If you want more tracability, there are tools for that.
But in my experience, I suspect that there's something else going on.
Have you considered that your team may feel that the process is broken/stupid/ineffective for most commits? Remember, process is documenting what works well, not rules to obey. And as the team lead, you're there to help them be their best, not enforce rules.
So in your retrospectives (if agile) or one on ones (if you're a manager) or in random impromptu hallway meetings (if you're a non-agile team lead and there's another manager doing one on ones), bring it up. Ask what people think of the code review process. How is it working? How is it not? Say you think it's maybe not benefiting the team as much as it could. Make sure you listen.
You can do some advocacy for code reviews in these meetings, but it's better to listen to the feedback. Most likely, you'll find that either you team thinks that the "proper" process needs adjusting, or that there is some root cause (time pressure, lack of reviewers, Bob just commits his code so why can't we) to address.
Forcing a tool on top of a broken process won't make the process any better.