github team code review assignment

Using the CODEOWNERS file in a GitHub project

September 19, 2023.

#development #github

GitHub offers a plethora of features to streamline project management and enhance collaboration among developers. Among these features, the CODEOWNERS file stands out as a powerful tool for managing code repositories efficiently. In this blog post, we'll delve into the CODEOWNERS file's capabilities and how it can help your team work more cohesively, ensuring code quality and project success.

Understanding the CODEOWNERS file

What is a codeowners file.

A CODEOWNERS file is a plain text file found within your GitHub repository. Its primary purpose is to specify who owns or is responsible for different parts of the codebase. This ownership information is crucial for assigning code review responsibilities, maintaining code quality, and ensuring accountability within your development team.

Why Use a CODEOWNERS file?

Streamlined Code Reviews : with a CODEOWNERS file in place, you can automate the assignment of code review requests. This means that pull requests automatically get assigned to the relevant code owners, saving time and ensuring thorough reviews.

Code Quality Assurance : by designating code owners, you establish accountability for specific parts of the codebase. This encourages developers to write high-quality, maintainable code, as they know their peers will review it.

Collaborative Workflow : the CODEOWNERS file fosters collaboration by clearly defining who to approach for questions, assistance, or guidance on particular code sections. It streamlines communication within the team.

Creating a CODEOWNERS file

Navigate to Your Repository : first, access your GitHub repository, and navigate to the root directory.

Create a New File : click on the "Add file" button and choose "Create new file."

Name Your File : enter .github/CODEOWNERS as the file name. The .github directory is a special location for GitHub-related files.

Define Ownership Rules : in the CODEOWNERS file, use a simple syntax to specify ownership. For example:

Here, we're assigning ownership of the frontend directory to the "frontend-team" and the backend directory to both the "backend-team" and the "dev-lead."

Commit Your Changes : finally, commit your CODEOWNERS file to the repository.

Leveraging the CODEOWNERS file in your workflow

Now that you have your CODEOWNERS file set up, let's see how to make the most of it in your GitHub project:

Automated Code Review Assignment : when team members open pull requests, GitHub will automatically assign reviewers based on the ownership rules you've defined in the CODEOWNERS file.

Clear Communication : team members can easily identify code owners when they have questions or need assistance, facilitating smoother collaboration.

Maintain and Update : periodically review and update your CODEOWNERS file to reflect changes in your team's structure or project needs. Keeping it up-to-date ensures its continued effectiveness.

Incorporating a CODEOWNERS file into your GitHub project is a simple yet powerful way to enhance collaboration, streamline code reviews, and improve code quality. By defining ownership and responsibilities, you can establish a clear workflow that benefits your entire development team. Embrace this tool to make your GitHub projects more efficient and successful.

Code review assignment (beta)

Teams can now be configured to assign a specified number of reviewers when a team is requested for code review. When coupled with CODEOWNERS , organizations can now ensure that code is reviewed by the proper team and automate distribution of code reviews across team members. Code review assignment is available for all users who are members of an organization as public beta.

Learn more about code review assignment on GitHub

GitHub Packages is generally available

Starting today, GitHub Packages (formerly GitHub Package Registry) is generally available. The use of GitHub Packages is free for all public repositories, and every plan gets included storage and data transfer for private repositories.

Learn more about GitHub Packages pricing

GitHub Actions is generally available

Starting today, GitHub Actions is generally available. GitHub Actions are free for all public repositories, and every plan gets included storage and runner minutes for private repositories.

Learn more about GitHub Actions pricing

DEV Community

Posted on Oct 21, 2023

Practical tips for code reviews in large teams

Improving the code review process is crucial for development teams aiming to maintain and elevate their efficiency and code quality. A growing list of pending pull requests (PRs) can be overwhelming and even demoralizing. By refining the review process, teams can ensure a balanced distribution of PRs, preventing certain team members from becoming inundated while others remain idle. Striving for equality in time spent on PRs helps in fostering a cohesive and harmonious team environment. Furthermore, adhering to a standard that aims for a review time of up to just one business day guarantees swift feedback and fosters a dynamic, responsive development cycle. Lastly, the essence of the improvement drive is to enhance the quality of PRs, ensuring they are optimally sized, adequately prepared, and comprehensive, which in turn streamlines the entire development process.

How to measure Code Review effectiveness

To gauge the efficacy of code review processes, it's essential to focus on team performance rather than individual contributions. Key metrics include the duration a pull request (PR) remains under review and the time a PR is in the review phase relative to its total lines of code. Monitoring the number of PRs that remain open and the volume of code within each PR can further provide insights into the efficiency of the review process.

Measure the effectiveness of the team rather than effectiveness of certain people
Measure time for how long PR stays in review state.
Measure time for how long a PR stays in review state divided by lines of code.
Number of PRs in open state.
Lines of code in PR

This can be achieved by introducing tools for collecting information about PRs. If you use Github there is a github action issue-metrics that can measure the average time of PRs staying in review for a certain period of time. But you can use Github API to create your own action that will collect information important for your project.

Example of report generated by issue-metrics

Prepare your PR

Always start by adding a detailed description to your PR . If a visual representation would help, consider including diagrams. Proposing a review plan can also be a game-changer, guiding reviewers through a logical sequence, ensuring no change gets overlooked. Before you request others to dive into your code, look through your draft PR yourself. This self-review allows you to catch and clean up any stray comments or oversights. Comments within your PR should clarify your coding decisions, especially if there's potential for confusion. For instance, if you addressed an unrelated bug during the current PR, mention it. This preemptive clarification can save reviewers a lot of head-scratching. Annotations act as a roadmap through your changes. By directing reviewers to specific files or explaining the rationale behind certain modifications, you make their job simpler. The added perk? You might spot errors during this annotation phase, fixing them even before the review starts. If you've addressed multiple issues in a PR, it might be the case that you need to divide it. PRs should be concise and focused. A rule of thumb: if a change touches more than five files, took over a day to draft, or would require an extensive review time, split it. For example, one PR could lay out the API for a new feature, and a subsequent PR could present the implementations.

How to review PRs of others

Treat code reviews with the same importance as any other task. Block off regular time slots in your calendar specifically for reviews. Swift feedback is crucial – the longer a developer waits, the hazier the context becomes, making it challenging to incorporate suggestions . Code reviews aren't solely about catching bugs. They offer an opportunity to familiarize yourself with the team's evolving features and coding principles. Embrace this chance to learn and grow. Your comments during a review should be lucid and constructive. Vague remarks can lead to confusion. Always aim to provide feedback that guides the developer towards the intended solution. While platforms like GitHub are fantastic for code hosting and initial reviews, they might not be the best for extended discussions. Consider moving prolonged conversations to a platform like Slack for a more dynamic exchange. For extensive pull requests, it can be beneficial to pull the branch into your local development environment. Tools like IntelliJ Idea can provide a more immersive diff view. Remember to use commands like git merge -no-commit -no-ff to see the changes as if you made them.

If you find certain parts of the code challenging to grasp, don't hesitate to ask the author in person for clarity. It's better to pause and understand than to provide feedback based on assumptions.

Reviewers Assignment Algorithm

There are different approaches to assigning reviewers automatically to PRs. For example randomly or using a matrix approach. GitHub provides two strategies https://docs.github.com/en/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team#about-auto-assignment An alternative approach would be to have a custom strategy where each team member has a list of reviewers from his squad, but also two temporary reviewers from other squads. Choose the approach which fits your team the best considering its size and feature delivering velocity.

The Speed of Code Reviews

While immediate reviews are ideal, they aren't always feasible. Nevertheless, a golden rule to adhere to is the 24-hour timeframe . Aim to respond to a code review request within one business day, even if it's just an initial assessment. This ensures that the code doesn't linger in review limbo, which could delay subsequent development stages. By adhering to this rule, it's likely that a typical Change List (CL) undergoes multiple rounds of review within a single day, if necessary. Such quick turnarounds not only streamline the development process but also facilitate dynamic discussions between the reviewer and the developer, leading to a more refined codebase.

How to address the review comments

Instead of solely relying on Github comments, use Slack Github connection to facilitate communication on the PRs. It offers a dynamic platform for real-time interactions, making it easier to clarify doubts, seek explanations, and reach consensus on suggested changes. If there's a particular comment or issue you plan to address later, leave a TODO tag accompanied by a task number. This ensures that you have a clear roadmap of pending actions and that these tasks aren't overlooked in future development stages. If a particular code section sparks extended debate, it's crucial to document the decisions made. By adding comments explaining the choices and rationale, you prevent repetitive discussions in the future. It serves as a reference, ensuring that future developers or reviewers understand the context and reasoning behind specific code segments.

Google guide: Code Review Developer Guide

Cisco research: https://static1.smartbear.co/support/media/resources/cc/book/code-review-cisco-case-study.pdf

Microsoft: 30 Proven Code Review Best Practices from Microsoft - Dr. McKayla

More readings on CR: https://blog.palantir.com/code-review-best-practices-19e02780015f

Top comments (6)

Templates let you quickly answer FAQs or store snippets for re-use.

Location London, Paris, EU
Joined Jan 2, 2019

Having worked with a lot of different teams with different code qualities, something I like to keep in mind: keep comments appropriate for the level of the code base you are working on.

For example, if the project is a total mess, there are no obvious patterns in use (or multiple abandoned patterns) and there is risky, badly written code all over the place. Accept that you won't be able to fix that in a code review, and that criticising every little thing is just going to demotivate your colleague. Unless you can say something that will make life easier for that developer, or there is an actual bug, staying quiet is a great option.

However if the project is extremely consistent and uses very clear patterns, you never want to allow that to be diluted by merging a PR that introduces structural issues or a competing pattern (unless it's part of an agreed refactor of course). If you see a PR like that you need to ask how that came to be: the developer wasn't on boarded properly, or doesn't understand the pattern and needs help, or simply disagrees and doesn't care. All of those need to be addressed outside of a code review.

Location WA, USA
Education Wildcard
Pronouns he/she/they (don't give a hoot)
Work Future She-EO of So-and-Such
Joined Oct 23, 2023

This was a fun read and some solid food for thought. Thank you!

I have a singular question. And ultimately it might come from a place of nativity. So heads up, if it's that. Would it be counterproductive to consider individuals from other squads (teams) reviewing code if it's meant to speed up the process? As individuals would then have to familiarize themselves with other's work. Versus an internal individual with a general understanding due to stand-ups and codebase/project knowledge?

That's the only part that has me scratching my head.

I've seen that on largish code bases where the squads are pretty loosely defined and everyone is working in the same repo, and it works pretty well IMO, increases shared knowledge of the project a little. Although you are right, it's harder to review a PR for a feature you know nothing about.

It could be more difficult if the teams are essentially working on two completely separate projects though, a few potential problems to look out for maybe:

Team A not caring about the code in Team 1 and just saying yes to everything
Team A asserting its superiority by nit picking Team 1s code unnecessarily
Team A finding it hard to understand Team 1s code (what you mentioned)

But if Team A are a client for Team 1s API then their input could be very valuable, so I guess it really depends. Try it for a few weeks and then review!

Eric, thanks for the response! I'm not in the field yet, so consider this more so reconnaissance. Figured all knowledge is good knowledge. The top two issues pointed out for team based operations were actually ones that I thought might be issues even on a round-robin level. As we all have our secret favorites on our team, and our personal preferences for how we like to be interacted with. So there's got to be some silent celebrations or frustrations being assigned to "the nice guy" or "the hard ass." Hahaha!

Now here's another probable-softball for you. Do code bases tend to have review-specs? Metrics code reviews must hit in order to be considered fulfilled? Because I feel like being more explicit about these things could clear up some confusion. Let me know if you've got the time, and thanks again!

Personality issues are seriously underestimated in software dev I think. A happy and secure team learns to write good code together. Insecure, pushy developers covering up for their imposter syndrome can totally destroy a project 🤷‍♂️

Great point about the review-specs, the more you can automate expectations the better (take a look at Danger JS for example). And yes for things that can't be automated, ideally there is a set of agreed conventions / patterns / decisions that can be referred to somewhere on a wiki say, to avoid extended discussions about things that already got decided previously

Heyyy, thanks for the response back! Isn't it funny how some individuals want exceptional treatment pertaining to themselves and are absolutely deaf when it comes to others. Oh, life! I desperately seek the ability to be a part of a team. I know I'm too green currently, but I really look forward to it down the line. I think it'll be a blast, but if it's not at least I'll learn something.

I'm taking all these pointers and putting them in the brain bin. I've been letting my Linter yell at me. But I would like to dive more into tests and automation at some point. Probably after I've got a better understand of the next step in the roadmap (absorbing some MERN). I've got Danger JS bookmarked. Thumbed through some of the docs. Would be fun to setup a bot, something new to do. Cheers!

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink .

Hide child comments as well

For further actions, you may consider blocking this person and/or reporting abuse

Advanced (Sub)Types in TypeScript You Need to Know

Nandani Sharma - Aug 16

Supercharge Your Frontend Skills: 8 Must-Have Tools for Developers in 2024 🚀

Sachin Gadekar - Aug 29

AppSec: The Security Specialty That Rules Them All

Michael Levan - Aug 16

Hints: Provide hints after a certain number of wrong guesses, such as whether the number is even or odd.

Avinash Mathi - Aug 15

We're a place where coders share, stay up-to-date and grow their careers.

AWS Certified Cloud Practitioner
AWS Certified Solutions Architect Associate
AWS Certified Developer Associate
AWS Certified SysOps Administrator Associate
AWS Certified Solutions Architect Professional
AWS Certified DevOps Engineer Professional
AWS Certified Advanced Networking Specialty
AWS Certified Security Specialty
AWS Certified Machine Learning Specialty
AWS Certified Database Specialty
AWS Certified Data Analytics Specialty
AWS Certified SAP on AWS – Specialty
Google Cloud Digital Leader
Google Associate Cloud Engineer
Google Professional Cloud Architect
Google Professional Data Engineer
Google Professional Cloud Developer
Google Professional Cloud DevOps Engineer
Azure Fundamentals – Exam AZ-900
Azure AI Fundamentals – Exam AI-900
Azure Data Fundamentals – Exam DP-900
Security, Compliance, and Identity Fundamentals – Exam SC-900
Azure Administrator Associate – Exam AZ-104
Azure Developer Associate – Exam AZ-204
Azure Security Engineer Associate – Exam AZ-500
Azure Network Engineer Associate – Exam AZ-700
Azure AI Engineer Associate – Exam AI-102
Azure Data Scientist Associate – Exam DP-100
Azure Data Engineer Associate – Exam DP-203
Azure Database Administrator Associate – Exam DP-300
Security Operations Analyst Associate – Exam SC-200
Identity and Access Administrator Associate – Exam SC-300
Azure Solutions Architect Expert – Exam AZ-305
Azure DevOps Engineer Expert – Exam AZ-400
Azure for SAP Workloads Specialty – Exam AZ-120
Azure Virtual Desktop Specialty – Exam AZ-140
Azure IoT Developer Specialty – Exam AZ-220
Cyber Security
More IT Certifications

How To Add Reviewers In Github

When it comes to streamlining code collaboration and ensuring the quality of your projects, adding reviewers in Github is a crucial step in the review process . By assigning specific individuals or teams to review your proposed changes, you can receive valuable feedback and enhance the overall project quality .

To add reviewers in Github , follow these simple steps:

Create a pull request for your changes.
After creating the pull request , you can ask a specific person or team to review the changes.
Keep in mind that repository ownership and access levels determine who can assign reviewers. You need to have write access to the repository to assign a reviewer.
Suggested reviewers are based on git blame data, but you can also request a review from a specific person by typing their username or the name of the team in the reviewers section.
If someone has already reviewed your pull request and you’ve made the necessary changes, you can re-request a review from the same reviewer.

It’s important to note that pull request authors can’t request reviews unless they are either a repository owner or collaborator with write access to the repository. This ensures that the review process is efficient and focused on the input of experienced reviewers.

By following these steps, you can streamline the code collaboration process in Github and ensure the highest level of project quality .

Requesting Review In Bitbucket vs GitHub

When it comes to requesting reviews on a pull request, the process differs between Bitbucket and GitHub. In Bitbucket , you can easily add reviewers directly to your pull request. However, in GitHub, you can only assign a pull request to one person. To include more people in the review process in GitHub, you can mention them in the comments.

Since December 2016, GitHub introduced the concept of review requests. This feature allows you to explicitly request a review from your collaborators. By requesting a review, you can ensure that the right individuals are notified and assigned to provide feedback on your code changes.

GitHub conveniently displays a list of people you are awaiting review from in the pull request page sidebar, making it easy to track progress. However, it’s important to note that review requests are only available for the owner of the repository, not the author of the pull request. Nevertheless, even as the author, you can still mention individuals in the comments to specifically request their review.

Comparing Requesting Review in Bitbucket versus GitHub

To provide a clearer understanding of the differences, here’s a comparison between requesting reviews in Bitbucket and GitHub:

Feature	Bitbucket	GitHub
Adding Reviewers	Directly in pull request	Assign to only one person
Notifying Additional People	N/A	Mention in comments
Review Requests	N/A	Introduced in December 2016
Visibility of Reviewers	N/A	Visible in pull request page sidebar
Availability	In Bitbucket	In GitHub

This table provides a quick overview of the key differences between requesting reviews in Bitbucket and GitHub. Each platform has its own approach to streamline the collaboration process and ensure effective code review.

Having a clear understanding of the requesting review process in both Bitbucket and GitHub empowers you to efficiently collaborate with your team and gather valuable feedback to improve your code quality.

Configuring Code Review Settings In GitHub

To reduce noise and clarify individual responsibility for pull request reviews in GitHub, you can configure code review settings . Two key settings that can significantly enhance your code collaboration process are team notifications and auto assignment .

Team Notifications

GitHub allows you to optimize team notifications when requesting reviews. By choosing to only notify requested team members, you can avoid sending notifications to the entire team when a specific member is requested to review a pull request. This setting is particularly useful when your repository is configured with teams as code owners and contributors are familiar with the specific individuals who would be the most appropriate reviewers. With team notifications , you can streamline the review process, reduce unnecessary noise, and ensure that the right people are involved in the code review.

Auto Assignment

To further customize the assignment of reviewers, GitHub provides the option of auto assignment . With auto assignment enabled, you can assign a specified subset of team members to review a pull request instead of the entire team. This feature allows you to distribute the review workload evenly, ensuring that each team member has a fair share of reviews while preventing overwhelming individuals. GitHub offers two algorithms for auto assignment:

Round Robin: This algorithm alternates between all members of the team, ensuring an equal distribution of reviews.
Load Balance: The load balance algorithm takes into account the number of outstanding reviews for each team member and assigns the pull request accordingly. This helps prevent any backlog of reviews and promotes a more balanced workload among team members.

In addition to these options, GitHub allows you to skip certain members, include child team members, count existing review requests, and more. These flexible settings give you full control over the assignment of reviewers, ensuring that the right team members are assigned to each pull request.

Configuring code review settings in GitHub is a powerful way to optimize your code collaboration process, reduce noise , and clarify individual responsibility. By leveraging team notifications and auto assignment, you can enhance the efficiency and effectiveness of your code review workflow, ultimately improving project quality and collaboration within your team.

– Avoid sending notifications to the entire team when a specific member is requested to review a pull request. | | Auto Assignment | – Assign a specified subset of team members to review a pull request.

– Optimize the distribution of reviews using algorithms like round robin or load balance.

– Skip certain members, include child team members, and count existing requests. |

Efficient code collaboration is crucial for maintaining project quality, and pull request reviews play a vital role in ensuring the integrity of code changes. By adding reviewers in GitHub, you can streamline the review process and enhance collaboration among team members.

Following the steps outlined in this guide, you can easily request reviews from specific individuals or teams, reducing noise and clarifying individual responsibility for pull request reviews .

GitHub’s code review settings offer additional customization options, allowing you to assign the right reviewers to each pull request. By leveraging these features, you can improve the efficiency and effectiveness of your code collaboration and review process on GitHub.

How can I add reviewers in GitHub?

To add reviewers in GitHub, you need to follow these steps:

1. Create a pull request. 2. Ask a specific person or team to review the changes you’ve proposed. 3. Keep in mind that repository ownership and access levels determine who can assign reviewers. 4. To assign a reviewer, you need to have write access to the repository. 5. Suggested reviewers are based on git blame data, but you can also request a review from a specific person by typing their username or the name of the team in the reviewers section. 6. Once someone has reviewed your pull request and you’ve made the necessary changes, you can re-request review from the same reviewer. 7. Pull request authors can’t request reviews unless they are either a repository owner or collaborator with write access to the repository.

Can I assign multiple reviewers to a pull request in GitHub?

No, in GitHub, you can only assign a pull request to one person. However, if you want to notify more people, you can mention them in the comments.

How do review requests work in GitHub?

Since December 2016, GitHub introduced review requests, which allows you to explicitly request a review from collaborators. You can see a list of people you are awaiting review from in the pull request page sidebar. It’s important to note that this feature is only available for the owner of the repository, not for the author of the pull request. The author can still mention the person in a comment to request a review.

How can I configure code review settings in GitHub?

To reduce noise and clarify individual responsibility for pull request reviews in GitHub, you can configure code review settings. There are two key settings: team notifications and auto assignment. When you choose to only notify requested team members, GitHub disables sending notifications to the entire team when the team is requested to review a pull request and a specific member of that team is also requested for review. This is useful when a repository is configured with teams as code owners , but contributors often know a specific individual who would be the correct reviewer. When enabled, auto assignment assigns a specified subset of team members to review a pull request instead of the whole team. GitHub provides two algorithms for assigning reviewers: round robin and load balance. The round robin algorithm alternates between all members of the team, while the load balance algorithm considers the number of outstanding reviews for each member. You can also configure settings to skip certain members, include child team members, count existing requests, and more.

How can adding reviewers in GitHub enhance code collaboration?

Adding reviewers in GitHub is an efficient way to streamline code collaboration and enhance project quality. By following the steps outlined in this guide, you can easily request reviews from specific individuals or teams, reducing noise and clarifying individual responsibility for pull request reviews. GitHub’s code review settings provide options to further customize the review process, ensuring that the right reviewers are assigned to each pull request. By leveraging these features, you can improve the efficiency and effectiveness of your code collaboration and review process on GitHub.

How to automate Code Reviews on Github

By Mukesh Thawani

Creating pull requests and reviewing them are two of the most common tasks in a developer’s daily schedule. Most projects have common guidelines which developers need to follow while creating and reviewing the pull requests.

Now, it is hard for developers to remember every guideline while making a pull request. It is even more difficult for reviewers to ensure that every line of code is compliant to the set guidelines.

We faced the same problem with our projects and solved it by automating the major part of the manual rote work. This made the lives of our developers and reviewers a lot easier. They spent more time improving code quality and less on common chores.

In this article, I will describe exactly how we did it, what all aspects of the process we automated and the tools we used for this.

Automate styling issues

We don’t want our reviewers asking the contributors to add the corresponding Jira issue number and description whenever they make a pull request. Instead, we have deployed a bot that does all the regular checks. This helps contributors to follow project guidelines.

Yes, a bot can verify if the description is present or not by checking the body of the pull request. It can comment on a pull request if the description is missing.

We can also add a pull request template to get some of the information related to the pull request. But this approach increases the friction required to create a pull request. When we add rules, we need to make sure that the experience of a new developer will be as frictionless as possible. At the same time, we need to maintain the code quality.

Now let’s look at the steps required in creating such a bot.

‘Danger’ to the rescue

Danger runs during your CI process, and gives teams the chance to automate common code review chores. This provides another logical step in your build, through this Danger can help lint your rote tasks in daily code review. You can use Danger to codify your team’s norms. Leaving humans to think about harder problems. She does this by leaving messages inside your PRs based on rules that you create with the Ruby scripting language. Over time, as rules are adhered to, the message is amended to reflect the current state of the code review. Danger is used in all sorts of projects: ruby gems, python apps, Xcode projects, blogs, npm websites and modules.

It will give you an abstraction on top of Github’s API to get details related to a pull request and perform the necessary checks. It is created and maintained by Orta and many other awesome contributors. After installation, you need to create a file named Dangerfile which will contain all the rules. This file should be present in the root of your project.

After adding this file you are all set with the rules. Now you need to run Danger every time someone creates a pull request.

Adding it to your CI workflow

We use Bitrise in our mobile SDK projects. It’s a Continuous Integration and Continuous Delivery service for mobile Apps. If you are using a different CI service then, you can check this guide on how you can integrate Danger with that service. There is a detailed blog post on integrating Danger with Bitrise. I will summarise it in five points:

Install bundler, create a Gemfile and add the Danger gem to the Gemfile.
Create a Dangerfile for your project.
Create a bot user on Github and a Personal Access Token for the bot.
Then add the generated token on Bitrise.
Add a script step in the project’s workflow. That’s it! ?

Rules which we can Automate

One of the ways to identify what rules we can automate is by looking at Github’s pull request API response. By comparing the API response with our pull request checklist or guideline, we can get an idea of the possibilities that are there. This is how the response looks like:

It returns almost all the information you see on GitHub’s pull request webpage like title, description, assignee, reviewers, labels etc.
There’s one more API to fetch a list of changed files. For each file, it will return the name of the file, the number of additions to the file, the number of deletions to the file.
We don’t have to use this APIs as we will be using Danger which gives us an easy way to interact with this data.

List of Rules we Automated

When we were adding Danger to our repository we looked at our requirements and some of the other projects which were using Danger. Below are some of the checks that we have in our projects.

Warn if it’s a big PR : We tend to make this mistake of pushing a lot of changes in one PR. Reviewing such PRs is a difficult task. We added a warning which shows up when the number of lines updated in a PR is more than 500.
Encourage pull request descriptions : Sometimes developers think that description is not necessary or we forget to add. Even though you mentioned the issue number, a brief description always helps and gives a context to the pull request. To see if the description is empty or not we can check the body length:

Check if the tests are missing : We all know tests are important and yet we tend to skip this step. Whenever we do any modification in the source code, we should add tests if possible. So, now it warns if there are any changes in the source code and the tests folder is not modified, which means new tests are missing.
Update Changelog : Added a new feature or fixed a bug — update the Changelog with the details. We made it mandatory to add a Changelog entry if the change is nontrivial. If the Changelog is not updated and pull request is not marked as trivial, then our CI fails the build. Now, we don’t have to keep track whether the Changelog was updated.
Encourage rebase not merge commits : As the project grows it’s always recommended that we should avoid ‘merge’ commits so that the project has a clean history. We prefer using rebase instead of merging different branches. We can add a check for messages of this format: “Merge branch ‘master’” to avoid the merge commits.

Where to go next

For reference, you can check ApplozicSwift’s Dangerfile or in some of the other popular open source projects like React Native or CocoaPods . I discovered while writing this blog post that projects like React Native and React were also using danger. This shows us how this process of automating these checks has become part of the common pull requests workflow.

Liked the story? Hit that clap button and follow me on Medium . Thanks for reading! This article was originally published on Kommunicate blog .

Learn to code. Build projects. Earn certifications—All for free.

If you read this far, thank the author to show them you care. Say Thanks

Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. Get started

Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
OverflowAI GenAI features for Teams
OverflowAPI Train & fine-tune LLMs
Labs The future of collective knowledge sharing
About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

How to automatically request a review from someone using GitHub actions?

I would like to use a GitHub action/do some config that automatically requests a review from a team in a GitHub organization (for example core ). I know that you can create pull request templates that automatically request a review from a certain reviewer but how do I do this without creating a template? In summary, I would like to have a team in GitHub core automatically requested a review for each PR opened. How do I do this?

github-actions

That's what code owners are for. – Benjamin W. Commented Mar 10, 2021 at 2:33
Is it possible to do automatically request a review from a team that doesn't have write access to the repository and just triage? – Henry Commented Mar 13, 2021 at 1:30
There is a role for exactly that (in GitHub Organizations): it's called "triage" (see here ). You can create a team containing the people whom you want to review, then give that team "triage" role in your repository and also set the team as code owners. – Benjamin W. Commented Mar 13, 2021 at 1:49
Oh, no, code owners can't have only the "triage" role, it requires at least "write". – Benjamin W. Commented Mar 13, 2021 at 1:50

In general, this is a good use case for the code owners feature: you could have a file .github/CODEOWNERS that looks like

This requests a review from that team on any pull request opened.

However, this requires the team to have write permissions on the repository, and (as per comments) the intention is to not give this team write permissions.

With the team having only "triage" permissions, this could be achieved with the following workflow:

This runs on each opened pull request and creates a review request from the yourorg/core team using the pr edit command of the GitHub CLI , which is pre-installed on the virtual environments.

1 In some organizations this may not work: With permissions:'write-all' : error fetching organization teams: Resource not accessible by integration – Drewry Pope Commented Oct 31, 2021 at 22:53
@DrewryPope That probably depends on the default permissions of the GITHUB_TOKEN , though I'm not sure which scope would apply to this specific error. – Benjamin W. Commented Nov 2, 2021 at 16:59
Having bumped into this myself just now, it looks like the only solution is to use a personal access token with, probably, the repo and read:org scopes, at least. – Benjamin W. Commented Sep 23, 2022 at 16:27

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged github yaml github-actions or ask your own question .

The Overflow Blog
At scale, anything that could fail definitely will
Best practices for cost-efficient Kafka clusters
Featured on Meta
Announcing a change to the data-dump process
Bringing clarity to status tag usage on meta sites
What does a new user need in a homepage experience on Stack Overflow?
Feedback requested: How do you use tag hover descriptions for curating and do...
Staging Ground Reviewer Motivation

Hot Network Questions

Fetch grapghQl response in next js
What does "if you ever get up this way" mean?
Can you fix this error while creating alias for encryption and decryption by GPG in z-shell?
Asked to suggest referees 9 months after submission: what to do?
Nearly stalled on takeoff after just 3 hours training on a PPL. Is this normal?
Getting an UK Visa with Ricevuta
Is there more evidence for god than for Russell’s teapot?
How do I learn more about rocketry?
Why do the opposite of skillful virtues result in remorse?
In what instances are 3-D charts appropriate?
Largest number possible with +, -, ÷
Multiple alien species on Earth at the same time: one species destroys Earth but the other preserves a small group of humans
How to resolve this calculation prompt that appears after running the drawing program?
Risks of exposing professional email accounts?
"The earth was formless and void" Did the earth exist before God created the world?
Applying for different jobs finding out it is for the same project between different companies
Do all instances of a given string get replaced under a rewrite rule?
Can I Use A Server In International Waters To Provide Illegal Content Without Getting Arrested?
Does it make sense for the governments of my world to genetically engineer soldiers?
Is there a way to assign multiple meshes to an object and switch between them?
Could an empire rise by economic power?
micro usb is not giving 5v but instead vbus is giving 0.45v
Why is notation in logic so different from algebra?
Testing if a string is a hexadecimal string in LaTeX3: code review, optimization, expandability, and protection

The University of Chicago The Law School

Innovation clinic—significant achievements for 2023-24.

The Innovation Clinic continued its track record of success during the 2023-2024 school year, facing unprecedented demand for our pro bono services as our reputation for providing high caliber transactional and regulatory representation spread. The overwhelming number of assistance requests we received from the University of Chicago, City of Chicago, and even national startup and venture capital communities enabled our students to cherry-pick the most interesting, pedagogically valuable assignments offered to them. Our focus on serving startups, rather than all small- to medium-sized businesses, and our specialization in the needs and considerations that these companies have, which differ substantially from the needs of more traditional small businesses, has proven to be a strong differentiator for the program both in terms of business development and prospective and current student interest, as has our further focus on tackling idiosyncratic, complex regulatory challenges for first-of-their kind startups. We are also beginning to enjoy more long-term relationships with clients who repeatedly engage us for multiple projects over the course of a year or more as their legal needs develop.

This year’s twelve students completed over twenty projects and represented clients in a very broad range of industries: mental health and wellbeing, content creation, medical education, biotech and drug discovery, chemistry, food and beverage, art, personal finance, renewable energy, fintech, consumer products and services, artificial intelligence (“AI”), and others. The matters that the students handled gave them an unparalleled view into the emerging companies and venture capital space, at a level of complexity and agency that most junior lawyers will not experience until several years into their careers.

Representative Engagements

While the Innovation Clinic’s engagements are highly confidential and cannot be described in detail, a high-level description of a representative sample of projects undertaken by the Innovation Clinic this year includes:

Transactional/Commercial Work

A previous client developing a symptom-tracking wellness app for chronic disease sufferers engaged the Innovation Clinic again, this time to restructure its cap table by moving one founder’s interest in the company to a foreign holding company and subjecting the holding company to appropriate protections in favor of the startup.
Another client with whom the Innovation Clinic had already worked several times engaged us for several new projects, including (1) restructuring their cap table and issuing equity to an additional, new founder, (2) drafting several different forms of license agreements that the company could use when generating content for the platform, covering situations in which the company would license existing content from other providers, jointly develop new content together with contractors or specialists that would then be jointly owned by all creators, or commission contractors to make content solely owned by the company, (3) drafting simple agreements for future equity (“Safes”) for the company to use in its seed stage fundraising round, and (4) drafting terms of service and a privacy policy for the platform.
Yet another repeat client, an internet platform that supports independent artists by creating short films featuring the artists to promote their work and facilitates sales of the artists’ art through its platform, retained us this year to draft a form of independent contractor agreement that could be used when the company hires artists to be featured in content that the company’s Fortune 500 brand partners commission from the company, and to create capsule art collections that could be sold by these Fortune 500 brand partners in conjunction with the content promotion.
We worked with a platform using AI to accelerate the Investigational New Drug (IND) approval and application process to draft a form of license agreement for use with its customers and an NDA for prospective investors.
A novel personal finance platform for young, high-earning individuals engaged the Innovation Clinic to form an entity for the platform, including helping the founders to negotiate a deal among them with respect to roles and equity, terms that the equity would be subject to, and other post-incorporation matters, as well as to draft terms of service and a privacy policy for the platform.
Students also formed an entity for a biotech therapeutics company founded by University of Chicago faculty members and an AI-powered legal billing management platform founded by University of Chicago students.
A founder the Innovation Clinic had represented in connection with one venture engaged us on behalf of his other venture team to draft an equity incentive plan for the company as well as other required implementing documentation. His venture with which we previously worked also engaged us this year to draft Safes to be used with over twenty investors in a seed financing round.

More information regarding other types of transactional projects that we typically take on can be found here .

Regulatory Research and Advice

A team of Innovation Clinic students invested a substantial portion of our regulatory time this year performing highly detailed and complicated research into public utilities laws of several states to advise a groundbreaking renewable energy technology company as to how its product might be regulated in these states and its clearest path to market. This project involved a review of not only the relevant state statutes but also an analysis of the interplay between state and federal statutes as it relates to public utilities law, the administrative codes of the relevant state executive branch agencies, and binding and non-binding administrative orders, decisions and guidance from such agencies in other contexts that could shed light on how such states would regulate this never-before-seen product that their laws clearly never contemplated could exist. The highly varied approach to utilities regulation in all states examined led to a nuanced set of analysis and recommendations for the client.
In another significant research project, a separate team of Innovation Clinic students undertook a comprehensive review of all settlement orders and court decisions related to actions brought by the Consumer Financial Protection Bureau for violations of the prohibition on unfair, deceptive, or abusive acts and practices under the Consumer Financial Protection Act, as well as selected relevant settlement orders, court decisions, and other formal and informal guidance documents related to actions brought by the Federal Trade Commission for violations of the prohibition on unfair or deceptive acts or practices under Section 5 of the Federal Trade Commission Act, to assemble a playbook for a fintech company regarding compliance. This playbook, which distilled very complicated, voluminous legal decisions and concepts into a series of bullet points with clear, easy-to-follow rules and best practices, designed to be distributed to non-lawyers in many different facets of this business, covered all aspects of operations that could subject a company like this one to liability under the laws examined, including with respect to asset purchase transactions, marketing and consumer onboarding, usage of certain terms of art in advertising, disclosure requirements, fee structures, communications with customers, legal documentation requirements, customer service and support, debt collection practices, arrangements with third parties who act on the company’s behalf, and more.

Miscellaneous

Last year’s students built upon the Innovation Clinic’s progress in shaping the rules promulgated by the Financial Crimes Enforcement Network (“FinCEN”) pursuant to the Corporate Transparency Act to create a client alert summarizing the final rule, its impact on startups, and what startups need to know in order to comply. When FinCEN issued additional guidance with respect to that final rule and changed portions of the final rule including timelines for compliance, this year’s students updated the alert, then distributed it to current and former clients to notify them of the need to comply. The final bulletin is available here .
In furtherance of that work, additional Innovation Clinic students this year analyzed the impact of the final rule not just on the Innovation Clinic’s clients but also its impact on the Innovation Clinic, and how the Innovation Clinic should change its practices to ensure compliance and minimize risk to the Innovation Clinic. This also involved putting together a comprehensive filing guide for companies that are ready to file their certificates of incorporation to show them procedurally how to do so and explain the choices they must make during the filing process, so that the Innovation Clinic would not be involved in directing or controlling the filings and thus would not be considered a “company applicant” on any client’s Corporate Transparency Act filings with FinCEN.
The Innovation Clinic also began producing thought leadership pieces regarding AI, leveraging our distinct and uniquely University of Chicago expertise in structuring early-stage companies and analyzing complex regulatory issues with a law and economics lens to add our voice to those speaking on this important topic. One student wrote about whether non-profits are really the most desirable form of entity for mitigating risks associated with AI development, and another team of students prepared an analysis of the EU’s AI Act, comparing it to the Executive Order on AI from President Biden, and recommended a path forward for an AI regulatory environment in the United States. Both pieces can be found here , with more to come!

Innovation Trek

Thanks to another generous gift from Douglas Clark, ’89, and managing partner of Wilson, Sonsini, Goodrich & Rosati, we were able to operationalize the second Innovation Trek over Spring Break 2024. The Innovation Trek provides University of Chicago Law School students with a rare opportunity to explore the innovation and venture capital ecosystem in its epicenter, Silicon Valley. The program enables participating students to learn from business and legal experts in a variety of different industries and roles within the ecosystem to see how the law and economics principles that students learn about in the classroom play out in the real world, and facilitates meaningful connections between alumni, students, and other speakers who are leaders in their fields. This year, we took twenty-three students (as opposed to twelve during the first Trek) and expanded the offering to include not just Innovation Clinic students but also interested students from our JD/MBA Program and Doctoroff Business Leadership Program. We also enjoyed four jam-packed days in Silicon Valley, expanding the trip from the two and a half days that we spent in the Bay Area during our 2022 Trek.

The substantive sessions of the Trek were varied and impactful, and enabled in no small part thanks to substantial contributions from numerous alumni of the Law School. Students were fortunate to visit Coinbase’s Mountain View headquarters to learn from legal leaders at the company on all things Coinbase, crypto, and in-house, Plug & Play Tech Center’s Sunnyvale location to learn more about its investment thesis and accelerator programming, and Google’s Moonshot Factory, X, where we heard from lawyers at a number of different Alphabet companies about their lives as in-house counsel and the varied roles that in-house lawyers can have. We were also hosted by Wilson, Sonsini, Goodrich & Rosati and Fenwick & West LLP where we held sessions featuring lawyers from those firms, alumni from within and outside of those firms, and non-lawyer industry experts on topics such as artificial intelligence, climate tech and renewables, intellectual property, biotech, investing in Silicon Valley, and growth stage companies, and general advice on career trajectories and strategies. We further held a young alumni roundtable, where our students got to speak with alumni who graduated in the past five years for intimate, candid discussions about life as junior associates. In total, our students heard from more than forty speakers, including over twenty University of Chicago alumni from various divisions.

The Trek didn’t stop with education, though. Throughout the week students also had the opportunity to network with speakers to learn more from them outside the confines of panel presentations and to grow their networks. We had a networking dinner with Kirkland & Ellis, a closing dinner with all Trek participants, and for the first time hosted an event for admitted students, Trek participants, and alumni to come together to share experiences and recruit the next generation of Law School students. Several speakers and students stayed in touch following the Trek, and this resulted not just in meaningful relationships but also in employment for some students who attended.

More information on the purposes of the Trek is available here , the full itinerary is available here , and one student participant’s story describing her reflections on and descriptions of her experience on the Trek is available here .

The Innovation Clinic is grateful to all of its clients for continuing to provide its students with challenging, high-quality legal work, and to the many alumni who engage with us for providing an irreplaceable client pipeline and for sharing their time and energy with our students. Our clients are breaking the mold and bringing innovations to market that will improve the lives of people around the world in numerous ways. We are glad to aid in their success in any way that we can. We look forward to another productive year in 2024-2025!

About code owners

You can use a CODEOWNERS file to define individuals or teams that are responsible for code in a repository.

Who can use this feature?

People with write permissions for the repository can create or edit the CODEOWNERS file and be listed as code owners. People with admin or owner permissions can require that pull requests have to be approved by code owners before they can be merged.

You can define code owners in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see " GitHub’s plans ."

The people you choose as code owners must have write permissions for the repository. When the code owner is a team, that team must be visible and it must have write permissions, even if all the individual members of the team already have write permissions directly, through organization membership, or through another team membership.

Code owners are automatically requested for review when someone opens a pull request that modifies code that they own. Code owners are not automatically requested to review draft pull requests. For more information about draft pull requests, see " About pull requests ." When you mark a draft pull request as ready for review, code owners are automatically notified. If you convert a pull request to a draft, people who are already subscribed to notifications are not automatically unsubscribed. For more information, see " Changing the stage of a pull request ."

When someone with admin or owner permissions has enabled required reviews, they also can optionally require approval from a code owner before the author can merge a pull request in the repository. For more information, see " About protected branches ."

If a file has a code owner, you can see who the code owner is before you open a pull request. In the repository, you can browse to the file and hover over to see a tool tip with codeownership details.

Screenshot showing the header for a file. The cursor is hovering over the shield icon, which displays the tooltip "Owned by USER or TEAM (from CODEOWNERS line NUMBER)."

CODEOWNERS file location

To use a CODEOWNERS file, create a new file called CODEOWNERS in the .github/ , root, or docs/ directory of the repository, in the branch where you'd like to add the code owners. If CODEOWNERS files exist in more than one of those locations, GitHub will search for them in that order and use the first one it finds.

Each CODEOWNERS file assigns the code owners for a single branch in the repository. Thus, you can assign different code owners for different branches, such as @octo-org/codeowners-team for a code base on the default branch and @octocat for a GitHub Pages site on the gh-pages branch.

For code owners to receive review requests, the CODEOWNERS file must be on the base branch of the pull request. For example, if you assign @octocat as the code owner for .js files on the gh-pages branch of your repository, @octocat will receive review requests when a pull request with changes to .js files is opened between the head branch and gh-pages .

CODEOWNERS and forks

To trigger review requests, pull requests use the version of CODEOWNERS from the base branch of the pull request. The base branch is the branch that a pull request will modify if the pull request is merged.

If you create a pull request from a fork, and the base branch is in the upstream repository, then the pull request will use the CODEOWNERS file from that branch in the upstream repository. If the base branch is a branch within your fork, then the pull request will use the CODEOWNERS file from that branch in your fork, but this will only trigger review requests if the code owners are added to your fork specifically with write access.

When you view who is responsible for a file by hovering over , you will see information from the CODEOWNERS file for whichever branch in whichever repository you're looking at.

CODEOWNERS file size

CODEOWNERS files must be under 3 MB in size. A CODEOWNERS file over this limit will not be loaded, which means that code owner information is not shown and the appropriate code owners will not be requested to review changes in a pull request.

To reduce the size of your CODEOWNERS file, consider using wildcard patterns to consolidate multiple entries into a single entry.

CODEOWNERS syntax

Warning: There are some syntax rules for gitignore files that do not work in CODEOWNERS files:

Escaping a pattern starting with # using \ so it is treated as a pattern and not a comment
Using ! to negate a pattern
Using [ ] to define a character range

A CODEOWNERS file uses a pattern that follows most of the same rules used in gitignore files. The pattern is followed by one or more GitHub usernames or team names using the standard @username or @org/team-name format. Users and teams must have explicit write access to the repository, even if the team's members already have access.

If you want to match two or more code owners with the same pattern, all the code owners must be on the same line. If the code owners are not on the same line, the pattern matches only the last mentioned code owner.

In most cases, you can also refer to a user by an email address that has been added to their account, for example [email protected] . You cannot use an email address to refer to a managed user account. For more information about managed user accounts, see " About Enterprise Managed Users " in the GitHub Enterprise Cloud documentation.

CODEOWNERS paths are case sensitive, because GitHub uses a case sensitive file system. Since CODEOWNERS are evaluated by GitHub, even systems that are case insensitive (for example, macOS) must use paths and files that are cased correctly in the CODEOWNERS file.

If any line in your CODEOWNERS file contains invalid syntax, that line will be skipped. When you navigate to the CODEOWNERS file in your repository, you can see any errors highlighted. A list of errors in a repository's CODEOWNERS file is also accessible via the API. For more information, see " REST API endpoints for repositories ."

If you specify a user or team that doesn't exist or has insufficient access, a code owner will not be assigned.

Example of a CODEOWNERS file

Codeowners and branch protection.

Repository owners can update branch protection rules to ensure that changed code is reviewed by the owners of the changed files. Edit your branch protection rule and enable the option "Require review from Code Owners". For more information, see " About protected branches ."

Note: When reviews from code owners are required, an approval from any of the owners is sufficient to meet this requirement. For example, let's say that your CODEOWNERS file contains the following line:

This means that changes to JavaScript files could be approved by either @global-owner1 or @global-owner2 , but approvals from both are not required.

To protect a repository fully against unauthorized changes, you also need to define an owner for the CODEOWNERS file itself. The most secure method is to define a CODEOWNERS file in the .github directory of the repository and define the repository owner as the owner of either the CODEOWNERS file ( /.github/CODEOWNERS @owner_username ) or the whole directory ( /.github/ @owner_username ).

As an alternative to branch protection rules, you can create rulesets. Rulesets have a few advantages over branch protection rules, such as statuses, and better discoverability without requiring admin access. You can also apply multiple rulesets at the same time. For more information, see " About rulesets ."