Pull Requests

Pull requests (PRs) play a crucial role in modern software development. They serve as a structured mechanism for developers to propose and review changes to a codebase, fostering collaboration, enhancing code quality, and promoting transparency. Here’s why they are essential:

1. Code Review and Collaboration: Pull requests allow developers to request reviews from their colleagues. These PRs facilitate discussions around new features or bug fixes, ensuring that code changes are thoroughly examined and improved before merging into the main project repository1.
2. Isolation and Testing: Developers can create a branch or fork, make changes locally, and then submit a pull request. This isolation prevents disruptions to the main codebase and user experience. It also enables thorough testing and development without affecting the entire program1.
3. Streamlined Debugging: PRs provide a separate platform for discussing new features. Reviewers can leave comments directly on specific lines of code, addressing concerns, asking questions, and suggesting improvements. This streamlines the debugging process and ensures that issues are resolved within the context of the proposed changes2. In summary, pull requests enhance code quality through collaborative review, foster better team communication, ensure the stability of the main codebase, and streamline project management3. 🚀

Workflow

See Workflows for more details.

diagram source

Rules

1. Code should only make it to the main or release branch through a PR.
2. Each PR should be reviewed by a functional and technical reviewer.
   • PRs can't be merged until a reviewer from each group has approved (see Reviewers)
3. Any work item addressed in the PR should be added as a linked work item.
4. Each PR creator should fill in the PR Template details.
5. Users should try to include images and/or GIFs to summarize the work (when feasible).

Templates

Pull Requests should use the Rizing PR template to keep consistency across products. The template has defined sections to for the contributor to fill in, to ensure that they include the major necessary information for adequate testing and review of a PR.

🚀 Rizing Standard PR Template 🔗

Reviewers

Reviewer groups should be configured as required reviewers, based on the changed content. Groups should include multiple people so that PRs will not be delayed when one person is not available to approve. The policy should enforce that at least 1 member of the group approve the PR before it can be merged.

Standard PR Groups include:

1. Product Name Technical Reviewers

   ex: Omni Technical Reviewers

2. Product Name Functional Reviewers

   ex: Omni Functional Reviewers

3. Product Name Release Reviewers

   ex: Omni Release Reviewers

Reviewer Group Image Templates

Technical Reviewers

Functional Reviewers

Release Reviewers

Policies

Policies should be put in place to ensure tha when certain code changes, any relevant pipelines are ran/pass, and the appropriate reviewer groups are required to approve the PR before it can be merged.

Rules

main Branch

• Minimum number of reviewers: 2
• Allow requestors to approve their own changes: No
• Check for comment resolution: Required
• Limit merge types: Squash merge
• Build validations should be set to run testing and linting on code change
• Product Functional Reviewers and Technical Reviewers group is required to approve changes

release/* Branches

• Minimum number of reviewers: 1
• Allow requestors to approve their own changes: No
• Check for comment resolution: Required
• Limit merge types: Squash merge
• Build validations should be set to run testing and linting on code change
• Product Functional Reviewers and Technical Reviewers group is required to approve changes
• Product Release Reviewers group is required to approve changes

Completing PRs

When completing PRs, the following should be applied:

• Merge type: Squash commit
• Complete associated work items after merging: Yes
• Delete branch after merging: Yes
• Customize merge commit message: No