When working in teams, pull requests play an important role in knowledge transfer, building a team culture, and ensuring high-quality merges. For example, a developer A forks a Git project to work on a feature. Then, after several commits that implement that feature, developer A issues a pull request to his team (or certain developers depending on the project policy). Code reviewers start reviewing the code and inserting comments within the changed code regarding code style, enhanced code, potential bugs, improvement suggestions, etc. Developer A can reply to the comments and make the necessary changes and commit them. This process is iterative and can go on for while until the pull request is approved by the reviewers. Then developer A (or a certain developer) merges his fork with the main project.
This story happens, in large projects, with every feature request, bug fix, refactoring, or any task. The commits between the pull request and the merge can be seen as project-custom coding rules. Mining these code changes along with the discussions can help us understand the team culture and build automated tools for checking the rules.
This project can be scaled down to a seminar project, or up to a master thesis.