Welcome to our #100DaysOfOSS series. With this post, we've officially gone from A to Z!

Today, we're covering the letter "Z."

A couple of months ago, we launched the Intro to Open Source Course, which connects to another repository called guestbook. When the person taking the course gets to chapter five, they put their new-found knowledge to work and create a pull request on the guestbook.

Welcome to our #100DaysOfOSS series. Until October 31, we'll be doing Open Source Software (OSS) terms from A to Z. We'll be diving into a different letter of the English alphabet, uncovering OSS concepts, and sharing our thoughts on them.

Today, we're covering the letter "Y" and the difference between YAML and YML.

Welcome to our #100DaysOfOSS series. Until October 31, we'll be doing Open Source Software (OSS) terms from A to Z. We'll be diving into a different letter of the English alphabet, uncovering OSS concepts, and sharing our thoughts on them.

Today, we're covering the letter "X" for Xenial Xerus.

Welcome to our #100DaysOfOSS series. Until October 31, we'll be doing Open Source Software (OSS) terms from A to Z. We'll be diving into a different letter of the English alphabet, uncovering OSS concepts, and sharing our thoughts on them.

Today, we're covering the letter "W" for Workflow.

Welcome to our #100DaysOfOSS series. Until October 31, we'll be doing Open Source Software (OSS) terms from A to Z. We'll be diving into a different letter of the English alphabet, uncovering OSS concepts, and sharing our thoughts on them.

Today, we're covering the letter "V" for Version Control.

If you’ve read any of my previous posts, you know that I’m a fan of redefining contributions. But during Hacktoberfest, there’s more competition for the magic four pull requests (PRs). If we think of it like Moneyball for engineers, except limiting it to Hacktoberfest, we realize it's not about hitting home runs; it's about getting on base consistently and making strategic plays that contribute to the overall win. So, how do you become a top contributor during Hacktoberfest?

Welcome to our #100DaysOfOSS series. Until October 31, we'll be doing Open Source Software (OSS) terms from A to Z. We'll be diving into a different letter of the English alphabet, uncovering OSS concepts, and sharing our thoughts on them.

Today, we're covering the letter "U" for Upstream.

Welcome to our #100DaysOfOSS series. Until October 31, we'll be doing Open Source Software (OSS) terms from A to Z. We'll be diving into a different letter of the English alphabet, uncovering OSS concepts, and sharing our thoughts on them.

As a maintainer of a repository, it’s in your best interest to automate processes as much as possible. The CODEOWNERS file is one of those tools to help with automating processes.

I decided to write a post about the CODEOWNERS file after reading this comment from one of our awesome Octerns, Divyansh (@diivi), in a pull request (PR) where I added the file.

A CODEOWNERS file in GitHub is a special file used to specify who reviews and maintains specific files or directories in a repository. It helps with identifying code ownership and who should be notified when pull requests are made to those repositories.

For example, in this particular CODEOWNERS file there is the @open-sauced/engineering team.

When someone creates a PR for that repository, that team is automatically added as a reviewer.

This is really handy because you don’t need to go and manually add reviewers, and when it’s a PR from an external contributor, they can’t add reviewers so this is super useful for them and can avoid comments like, “Can someone review my PR?”

Another nice feature of the CODEOWNERS file is that it can be used as part of branch protection.

To enable this, go to the Protect matching branches section of a branch protection rule, and ensure the Require review from Code Owners option is checked.

One other thing to note is if you have permanent branches aside from main, like beta, dev, or whatever your team calls it, they can have different individuals and teams in those branches CODEOWNERS file.

How to add a CODEOWNERS file to your project​

The CODEOWNERS file is a special file that can reside in the root directory, in the .github directory or the docs directory (if you have one).

The .github folder might not exist in your project if you haven’t added other GitHub automated processes like GitHub Actions, pull request templates, or issue templates.

Also note, GitHub looks for the first CODEOWNERS file it finds, searching first in the root directory, then the .github directory, and finally, the docs directory (if it exists).

You can add individual GitHub users, a team, or a combination of them to a CODEOWNERS file.

A nice feature of adding or making changes to a CODEOWNERS file in a pull request is that GitHub validates it, letting you know if you are adding a non-existent user or team.

If you don’t already have a CODEOWNERS file file in your repository, I encourage you to add one. Let us know if you have any questions about this or other maintainer-related issues.

Stay saucy peeps!

If you would like to know more about my work in open source, follow me on OpenSauced.