Own it: GitHub introduces Code Owners
GitHub has rolled out a new feature to ensure code is properly reviewed before it’s added to a project. Step aside, cowboys, there’s a new sheriff in town and they are code owners.
Creating order from chaos, GitHub is trying to bring a little organization to adding new code to projects with their new code owners process. This clarifies the review process for new code and gives repository managers more of a say in whether new code gets added. According to GitHub, this new feature automatically requests reviews from the code owners when a pull request changes any owned files.
So, how does it work?
Code owners are people who own an area of code. Sounds simple enough.
Devs can own a small section, or a whole chunk of a repository. The idea is that if someone comes up with an awesome fix, they have to check with the wizard of that particular section of code. This ensures that code is pretty and doesn’t accidentally set a fire somewhere else.
Plus, it pinpoints exactly who is responsible for reviewing code and can move things along. Want to fix a bug in a small section? Let that specific code owner know! Got a high-level bug that needs a root level admin? Email that one person instead of messaging a bunch of people.
Code owners are just devs who really, really know this one section of code and have an over-invested sense of responsibility with it. They want this code to succeed and do well in school and not start fights with other snippets of code.
Chromium devs should be used to this format already: GitHub got the idea from them. According to Monica Dinculescu, who explained why Chromium has code owners:
Owners are gatekeepers of code, and their main responsibility is making sure the code doesn’t go to shit. Comments that make sense. No copy pasting, no hacks, no soup for you. None of that “I don’t really know how to make this code better so I’m going to merge it and run” nonsense. They are the very model of a modern Major-General, they know the kings of England, and they quote the fights historical.
TL; DR: owners won’t let you merge crappy code. Imagine if each of the 2000 Chromium committers merged a random hack in one of the 7 million lines of code we have. IMAGINE. 🔥🔥🔥
Besides, if people move on from the project, they can be replaced with new fanatics and the project isn’t left with a ghostly phonebook full of MIA devs.
What does it mean for code owners?
If you’re an owner, people are going to send you a lot of code to review, since your approval is necessary for code to be committed. People are going to message you with questions a lot, too. You don’t have to know all the answers, but you should be able to flail around and point them in the right direction.
If you’re the poor schmuck who’s the code owner of a buggy string of code: bad luck mate, it’s your problem now. Sometimes that means fixing code someone else broke. Sorry!
On the plus side, you get to be extra picky with code. Don’t like the comments? A method name? Think there’s too much spaghetti code? Congrats, you get to say “no, try again” to whatever dev who brought it to you. Try not to go too mad with power.
The protected branch option ensures that the right people have a chance to review code before it’s committed. A code owner for each owned file has to leave a review before anyone can merge a pull request to that branch.
And for devs?
Well, obviously, if you have a problem, you know exactly who to contact. Also, if you want to make a change, you need approval.
“Developers trust owners to not be insane,” says Dinculescu. “Owners trust developers not to try to commit stuff behind their back. This is why it works.”
Interested? Head on over to GitHub and take a look at their code owners info page.