Our team has three seniors. We have 3 juniors and more coming up.

We want to have some set of organization in our git repos. I want the three of us to be required reviewers for the team repos, but we three should be able to merge pull requests for our codes without having to get it code reviewed by the other two.

I tried setting up a codeowners file in github with our team admin group as the codeowner, but it is making me unable to merge PRs for my code without the other two reviewing it. I can add our individual handles as code owners, but that would mean I would need to update every individual repo if we get a new admin or one of us goes away.

What is the best way to achieve what I’m looking for? Please advise.

    • nieceandtows@programming.devOP
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 year ago

      Frankly, I’m the only (senior) programmer in the team, and the other two can write only serviceable python scripts, so I don’t need them to review my code. They are seniors in the data itself, and mostly add/maintain other kinds of files/repos like sqls and other data related files that I don’t need to review.

      • aport@programming.dev
        link
        fedilink
        arrow-up
        17
        ·
        1 year ago

        One good reason to have juniors review your code is for them to become familiar with not only the codebase itself, but best practices.

      • Transient Punk@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        15
        ·
        1 year ago

        That’s a pretty bad take. Everyone can make mistakes, and different perspectives are always beneficial. Reviewing your code may give some of the other devs a chance to learn. Who knows, they may even catch a mistake that you may miss.

          • Lmaydev@programming.dev
            link
            fedilink
            arrow-up
            3
            ·
            1 year ago

            Writers bias is real and even a less experienced set of eyes can spot a silly mistake that you’ve overlooked because you wrote it.

            It’s also a good learning experience for juniors. Seeing more skillfully written code and being able to ask questions about why you took an approach.