Pull Requests: Submitting pull requests to any repository in Collabo Community

Last updated 6 months ago

Was this helpful?

Pull Requests: Submitting pull requests to any repository in Collabo Community

Try to submit a pull request for an issue within 2 days of showing interest, even if you are not through fixing the issue, so that the associated issue ticket doesn't get reassigned to another contributor. Seeing some form of activity about it frequently (either on the issue ticket/pull request or in our community channels) will help the community know you are actively working on it.

PR 101: How to submit pull requests that make the work of reviewers and repository maintainers less complicated

Do not submit a pull request for an issue ticket you are not assigned to. It will be counted as spam. Reason: We want to be clear about who is working on what, and we want to avoid more than one person working on the same issue ticket without knowing it.
The name of your branch should use the branch naming convention in our . Reason: It is a way of confirming to maintainers/reviewers, that the issue ticket you are submitting a fix for exists on GitHub. Making use of the ticket's issue number in the branch name, makes it easy to identify and associate the fix you are submitting to the GitHub issue ticket.
Link your pull request to the issue it aims to fix. Do this in description of the pull request you are submitting. Reason: The link helps reviewers to easily locate the associated issue ticket. to help understand how to link pull request to issue ticket.
Your pull request title must reflect the Issue title you are working on, and it should start with "Fix: ". For example, If the issue title is "Add contribution rules section", the pull request title should be "Fix: Add contribution rules section". Reason: This helps the internal team easily locate and quickly identify the associated pull requests to your issue tickets, when issuing release notes for the product or for any other reference purpose.
Only make changes that the issue asks to change. Do not change even as small as space or comma anywhere else that does not concern the issue ticket you are taking on. Reason: Reviewers will not have to deal with anything apart from what is in the issue ticket associated with the pull request. Reviewers can therefore focus, be thorough and do it with little or no fatigue. It is possible that more than one contributors are working on the same specific file(s) you are working on. Help make it easier for maintainers to merge these possibly conflicting changes from different contributors successfully, without "merging away" things we need by mistake. Also, If we discover that some pull request fix is later problematic after we have merged it in, we may need to revert (i.e. remove) the affected pull request fix. If changes for some other different issue are done in the same fix, this means we'll be removing all of them instead of just that one cause - which is what we don't want. Making reference to pull requests that contain more than the changes asked in the future is also problematic.
Do not request review from an individual person when you want to request for review on your pull request (once you are done and you feel that your pull request is ready for review). Instead, request review from a review team. Reason: The review teams are created so that more than one persons can receive notifications to review your pull request. If one person is not around to review, some other reviewer can take it up. At the same time, you don't have to worry about who to tag or request review from, even if the maintainers of the project change. Extra note: This does not mean that persons who are not on the review teams cannot review a pull request.

What are the review teams, and which review team to request review from for the project you are contributing to?

Review teams are the way we assign the responsibility to people within our community to review pull requests that come in from contributors, based on their area of interest(s) or expertise. The people in these review teams are also contributors themselves.

The list of review teams can be found at:

Brief description of the review teams:

collabo-community/review-docs team review documentation related GitHub pull requests.
collabo-community/review-web-client team reviews GitHub pull requests that are frontend web related.
collabo-community/review-mobile-client team reviews Github pull requests that are mobile app client related.
collabo-community/review-backend team reviews Github pull requests for backend-only solutions.
collabo-community/review-fullstack team reviews Github pull requests that are fullstack (i.e. frontend + backend) in nature.
collabo-community/review-cli team reviews Github pull requests for CLI projects.
collabo-community/review-library team reviews Github pull requests for the libraries we build.

Even if more review teams are added or they change in the future, we follow a stable and predictable pattern for naming the review teams.

Review teams can be easily identified, as review- is present in the team name.

How to request review from a review team on your pull request

After submitting your pull request, and anytime you feel your pull request is ready for reviewers to take a look, go to the reviewers dropdown there in your pull request. Then select a review team from the drop down list. You will only find one review team on the list, so just select that one.

For example, in the screenshot below, the contributor is selecting the collabo-community/review-docs review team because they are submitting the pull request to the documentation repository.

If you are not able to access the dropdown to request review as shown in the screenshot below, just add a comment on the pull request tagging the correct review team. Example comment: "Pull request ready for review @collabo-community/review-docs".

Feel free to ask questions in the community channels, if you are not clear about anything written on this page.

Last updated 6 months ago

Was this helpful?

PR 101: How to submit pull requests that make the work of reviewers and repository maintainers less complicated

Do not submit a pull request for an issue ticket you are not assigned to. It will be counted as spam. Reason: We want to be clear about who is working on what, and we want to avoid more than one person working on the same issue ticket without knowing it.
The name of your branch should use the branch naming convention in our . Reason: It is a way of confirming to maintainers/reviewers, that the issue ticket you are submitting a fix for exists on GitHub. Making use of the ticket's issue number in the branch name, makes it easy to identify and associate the fix you are submitting to the GitHub issue ticket.
Link your pull request to the issue it aims to fix. Do this in description of the pull request you are submitting. Reason: The link helps reviewers to easily locate the associated issue ticket. to help understand how to link pull request to issue ticket.
Your pull request title must reflect the Issue title you are working on, and it should start with "Fix: ". For example, If the issue title is "Add contribution rules section", the pull request title should be "Fix: Add contribution rules section". Reason: This helps the internal team easily locate and quickly identify the associated pull requests to your issue tickets, when issuing release notes for the product or for any other reference purpose.
Only make changes that the issue asks to change. Do not change even as small as space or comma anywhere else that does not concern the issue ticket you are taking on. Reason: Reviewers will not have to deal with anything apart from what is in the issue ticket associated with the pull request. Reviewers can therefore focus, be thorough and do it with little or no fatigue. It is possible that more than one contributors are working on the same specific file(s) you are working on. Help make it easier for maintainers to merge these possibly conflicting changes from different contributors successfully, without "merging away" things we need by mistake. Also, If we discover that some pull request fix is later problematic after we have merged it in, we may need to revert (i.e. remove) the affected pull request fix. If changes for some other different issue are done in the same fix, this means we'll be removing all of them instead of just that one cause - which is what we don't want. Making reference to pull requests that contain more than the changes asked in the future is also problematic.
Do not request review from an individual person when you want to request for review on your pull request (once you are done and you feel that your pull request is ready for review). Instead, request review from a review team. Reason: The review teams are created so that more than one persons can receive notifications to review your pull request. If one person is not around to review, some other reviewer can take it up. At the same time, you don't have to worry about who to tag or request review from, even if the maintainers of the project change. Extra note: This does not mean that persons who are not on the review teams cannot review a pull request.

What are the review teams, and which review team to request review from for the project you are contributing to?

The list of review teams can be found at:

Brief description of the review teams:

collabo-community/review-docs team review documentation related GitHub pull requests.
collabo-community/review-web-client team reviews GitHub pull requests that are frontend web related.
collabo-community/review-mobile-client team reviews Github pull requests that are mobile app client related.
collabo-community/review-backend team reviews Github pull requests for backend-only solutions.
collabo-community/review-fullstack team reviews Github pull requests that are fullstack (i.e. frontend + backend) in nature.
collabo-community/review-cli team reviews Github pull requests for CLI projects.
collabo-community/review-library team reviews Github pull requests for the libraries we build.

Even if more review teams are added or they change in the future, we follow a stable and predictable pattern for naming the review teams.

Review teams can be easily identified, as review- is present in the team name.

How to request review from a review team on your pull request

For example, in the screenshot below, the contributor is selecting the collabo-community/review-docs review team because they are submitting the pull request to the documentation repository.

Feel free to ask questions in the community channels, if you are not clear about anything written on this page.

This YouTube playlist from our old Git and Github course content may also help you when contributing to any of our projects.