How does code review work in an open source project?
Tags: spo600
Published: 2023-09-06 23:15:34

Here are two examples of open-source software packages for this review.
1. NextAuth.js https://github.com/nextauthjs/next-auth
2. Backstage https://github.com/backstage/backstage

## NextAuth.js 
Link: https://next-auth.js.org/

NextAuth.js primarily uses pull requests on GitHub to accept code ("patches") from contributors. Every pull request (PR) needs to be approved by a core contributor before merging. Contributors must provide corresponding documentation and include it as part of the pull request when adding new functionality.

When submitting a PR on GitHub, contributors need to go through several steps in terms of explaining why this change needs to be addressed. This includes a checklist, affected issues, and resources. Once submitted, the Vercel GitHub bot automatically deploys the PR to Vercel, allowing users to preview the changes made before they are pushed to the main branch. A main contributor will review the PR and decide whether to approve it or request changes.

### Example of a Pull Request
Link: https://github.com/nextauthjs/next-auth/pull/8266

A total of four people were involved in the review: two main contributors, one member, and one author who submitted the PR. The entire PR review process took a day, and both the reviewer and the author were very responsive to updates during the process. The issue addressed the support for multi-project schemas in the drizzle adapter, as the adapter for users with custom table functions wouldn't find the appropriate tables, resulting in an error. The issue was resolved by adding new methods to support multi-project schemas.

### Advantages of Using Pull Requests as a Way of Contributing:

- Code Review: Pull requests facilitate code review by allowing team members to assess proposed changes. This process helps identify errors, improve code quality, and ensure adherence to coding standards.

- Collaboration: They promote collaboration among team members. Contributors can work on their own branches, making changes independently without disrupting the main codebase until they're ready to merge.

### Disadvantages of Using Pull Requests as a Way of Contributing:

- Time-Consuming: The code review process can be time-consuming, especially for large projects with many contributors. It may delay the integration of new features or bug fixes.

- Conflict Resolution: When multiple contributors work on different parts of the codebase simultaneously, conflicts can arise during the pull request merge process. Resolving conflicts can be challenging and time-consuming.

### Personal Thoughts:

I would follow the contributor rules as indicated, as I do not own the project and believe I have no control over it. Additionally, I am a strong advocate for using pull requests, as I believe that no code is perfect, and a thorough code review is essential to avoid potential issues.

## Backstage
Link: https://backstage.io/

Backstage primarily uses pull requests on GitHub to accept code ("patches") from contributors. However, they also use other communication tools, like Discord.

Contributors create a new issue, describing the bug they have found and start working on fixing it. Once they fix the bug, they will create a pull request. Every pull request needs to be approved by a member before merging. Contributors also need to include changesets in their pull request, ensuring that every package affected by the change gets a proper version number and an entry in its CHANGELOG.md. When submitting a PR on GitHub, contributors specify a checklist of what kinds of changes were made in this PR.

### Example of a Pull Request
Link: https://github.com/backstage/backstage/pull/19720

A total of six people were involved in the review: five members/maintainers, and one author who submitted the PR. The entire PR review process took four days, and both the reviewer and the author were very responsive to updates during the process. The reviewer made a few comments on some of the code, and the author made some changes based on the comments.

The issue addressed the fix of not being able to add a new policy to the permission plugin when using the backend featureDiscoveryServiceFactory. The issue was resolved by installing a new package, allowing all policy backend modules for the permission plugin.

### Advantages of Finding and Fixing a Bug Themselves:
- Faster Development: By addressing bugs promptly, development can progress more smoothly without the interruption of unresolved issues, leading to faster overall project development.

- Ownership and Responsibility: Taking responsibility for finding and fixing bugs fosters a sense of ownership and accountability for one's work. It promotes a proactive and responsible attitude toward code quality.

- Reduced Communication Overhead: Self-debugging eliminates the need for extensive communication to report and explain the bug to others. This can be especially advantageous in time-sensitive or critical situations.

### Disadvantages of of Finding and Fixing a Bug Themselves:
- Blind Spots: A developer may overlook certain aspects of the code, leading to a partial or incomplete fix. This can result in the bug resurfacing later.

- Loss of Collaboration Opportunities: Debugging is an opportunity for team members to collaborate and learn from each other. Solving bugs individually may limit knowledge-sharing and skill development.

- Potential for Tunnel Vision: Focusing exclusively on a single bug may lead to neglect of other important tasks or issues in the project.

### Personal Thoughts:
I would look at the code and play around with it to see if I can find any bugs and start debugging. Once finished, I will create a PR along with the changesets which are also required.