How To Be Sheriff In Huge Open Source Project

I'm presently involved as a kind of maintainer in this massive project. You can read more here.

First of all, wait wait wait, what means sheriff?

Sheriffs help steward and manage the project's infrastructure and ensure that the team can function optimally at all times. Their primary role is to help developers shepherd their code through the review process to be landed cleanly and do so without breaking any tests, CI automation, or infrastructure.

In this post, you will follow the process of being the sheriff
from my experience:

Where to start? Issues are always an answer.
Can I approve changes? Let's break production.
The pros/cons? Sleep schedule.

Where to start?

The telescope is enormous and consists of different parts like monolithic backend, frontend, and many services.

It's complicated to know all the parts of the code and be actively involved in each issue. Still, if you will ever join any open-source, your step zero, of course, should be the architecture of the app, but after this, run into open issues and try to read code that the contributors are implementing in recent changes. This way, you will understand what they are doing and learn things about the issue. It can be challenging. Also, it can take plenty of time and energy to comprehend something, but as my professor told me, we review code not to check it only but to ask questions about something we don't understand.

Can I approve changes?

At first, I didn't even know that I could merge changes into the main repo, and this hit me when our production and development stages broke because of a new dependencies update. After a few hours of arduous searching around the source code, the issue was solved. There are three things to remember before merging:

wait for at least two approves(three even better)
check all the CI
rebase all commits into one

The pros/cons?

Communication
Team meetings
24/7 support, so the system won't fall

Being a sheriff was a wonderful time because I was actively involved in the project and noticed how it consistently progressed. Of course, it was a lot of communication around each issue, and on the one hand, it helped. On another, it isn't. For me, a team meeting was a bit stressful at first, but I got along in a time. We divided our responsibilities with my partner, so monitoring the system wasn't so complicated. The best and worst parts of the open-source project seemed like communication.