Skip to content

Commit cf27062

Browse files
praneentrendexpraneentrendex
committed
Feature: Addition of pull request guideline page
1 parent 9b788d4 commit cf27062

File tree

3 files changed

+140
-5
lines changed

3 files changed

+140
-5
lines changed

‎docs/git/pull-request-best-pratices.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,4 +12,4 @@ sidebar_label: Pull Request Best Practices
1212
* If there are pending, not resolved comments, the assignee is a code author who should fix or comment back.
1313
* If there are discussions commented by the code author, the assignee is reviewer, who should continue a discussion or resolve comments and approve.
1414
* Use labels to mark what actions should be next – e.g. `needs review`, `Reviewed By... ` etc.
15-
* Provide details/screenshots about what has been changed.
15+
* Provide details/screenshots about what has been changed.

‎docs/git/pull-request-guidelines.md

Lines changed: 135 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,135 @@
1+
---
2+
id: pull-request-guidelines
3+
title: Pull Request Guidelines
4+
---
5+
6+
7+
# Generic Pull Request Guidelines
8+
9+
10+
## Creator Guideline
11+
12+
13+
14+
* Reflect the story/task/ in JIRA to GIT - Description, Link, Design reference, Any additional info.
15+
* Think simple
16+
* Compose clean, elegant, and readable code.
17+
* Document only meta information inadequately represented by code
18+
* Focus on the Statement of user value
19+
* Create a branch equivalent to the JIRA ticket - PROJECT-XXX
20+
* Push your code
21+
* ASAP - As soon as possible
22+
* AFAP - As frequently as possible
23+
* The goal here is to collaborate well with the latest changes. Build once and use many times.
24+
* Requesting for appropriate reviewers. Follow the steps as
25+
* Drafting pull requests
26+
* Review by self
27+
* Review by others
28+
* Timely acknowledge feedback on the pull requests
29+
* Be patient about pull requests
30+
* Not parallelize too much and create multiple pull requests
31+
* In-progress limit of at max 2 pull requests
32+
* Proper closure and definition of done
33+
* Open Mindset
34+
* Acceptive
35+
* Open to enhancements/improvements
36+
37+
38+
## Reviewers Guideline
39+
40+
41+
42+
* Open Mindset
43+
* Acceptive
44+
* Open to enhancements/improvements
45+
* Go over the ticket description to understand what the PR is for
46+
* Solution-driven comments over criticisms
47+
* Knowledgeable comments
48+
* Suggestive commenting
49+
* Be polite and respectful
50+
* Don’t just comment for the sake of it
51+
52+
53+
## Approval Guideline
54+
55+
56+
57+
* Meets business requirements
58+
* Adherence to the technical guidelines listed below
59+
* Resolution of obvious bugs
60+
* Keep an eye out for nonfunctional requirements
61+
* Performance and scalability
62+
* Portability and compatibility
63+
* Reliability, maintainability, and availability
64+
* Security
65+
* Localization
66+
* Usability
67+
* Resolution of conflicts
68+
* Minimum reviewal by two individuals
69+
70+
71+
## Things to keep in mind
72+
73+
74+
75+
1. Granularization of tasks
76+
1. Small biteable size of code
77+
1. Easy portability - Cherry-pick
78+
2. Incremental effect analysis - Easy recovery
79+
3. Easy comprehension
80+
2. Learning process for the reviewer and reviewee
81+
3. Alignment to git strategy
82+
2. [Git flow](https://danielkummer.github.io/git-flow-cheatsheet/)
83+
4. [Clean Code](https://github.com/SaikrishnaReddy1919/MyBooks/blob/master/%5BPROGRAMMING%5D%5BClean%20Code%20by%20Robert%20C%20Martin%5D.pdf)
84+
5. Strictly follow design principles.
85+
3. DRY
86+
4. KISS
87+
5. YAGNI
88+
6. SOLID
89+
6. Conventions
90+
7. [Naming conventions](https://github.com/kettanaito/naming-cheatsheet)
91+
7. Proper Use of inbuilt functions
92+
8. Only wrap exceptional logic in try catch.
93+
9. Avoid unnecessary else statements.
94+
10. Consistent return
95+
8. Use of Packages
96+
11. After a brief consultation with application team members.
97+
12. Freeze package names for major versions
98+
9. Keep an eye out for functional and object-oriented concepts.
99+
10. Component-based development
100+
13. Use of non unique ids. Component composition rule violation.
101+
14. Keep reusability in mind
102+
15. Avoid side effects
103+
16. Schema driven development
104+
105+
106+
## Pull request description
107+
108+
Please note a few things while opening your PRs. Add the following things to your PR's description.
109+
110+
111+
112+
* Description - A short description of the feature for which the PR is opened.
113+
* Summary of changes - Changes in the source code which the PR comprises.
114+
* Route - The route from where we can view the feature being added in this PR.
115+
* Screenshot - A screenshot of the added feature.
116+
* Deployment notes - Any environment-specific changes need to be made in terms of infrastructure. Eg: Seeding of tables, the addition of secrets to the secrets manager, migration of tables, etc.
117+
118+
Also, make sure to add some reviewers and assign yourself as an Assignee.
119+
120+
#### Best Practices:
121+
122+
* Pull Request should atleast be <b>reviewed by 1 person</b> before merging it to the base branch.
123+
* Only comment author can resolve comment – if code was corrected or after discussion author decides to fix it.
124+
* Don’t mention the same problem many times. Don’t bloat the code, say it once and ask to fix everywhere.
125+
* If there are pending, not resolved comments, the assignee is a code author who should fix or comment back.
126+
* If there are discussions commented by the code author, the assignee is reviewer, who should continue a discussion or resolve comments and approve.
127+
* Use labels to mark what actions should be next – e.g. `needs review`, `Reviewed By... ` etc.
128+
* Provide details/screenshots about what has been changed.
129+
130+
References
131+
132+
133+
134+
1. [https://github.com/exercism/docs/blob/master/contributing/pull-request-guidelines.md](https://github.com/exercism/docs/blob/master/contributing/pull-request-guidelines.md)
135+
2. [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)

‎sidebars.js

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@ module.exports =
33
"docs": {
44
"Overview": [
55
"introduction",
6-
"general/clean-code"
6+
"general/clean-code",
77
],
88
"REST API": [
99
"rest-api/headers",
@@ -24,6 +24,8 @@ module.exports =
2424
"rest-api/versioning"
2525
],
2626
"Git & GitHub": [
27+
"git/pull-request-guidelines",
28+
"git/code-review-checklist",
2729
"git/branch-naming-convention",
2830
"git/branching-strategy",
2931
"git/smart-commit",
@@ -33,9 +35,7 @@ module.exports =
3335
"items": [
3436
"git/tagging"
3537
]
36-
},
37-
"git/pull-request-best-pratices",
38-
"git/code-review-checklist"
38+
}
3939
],
4040
"Python": [
4141
"python/environment-and-dependency",

0 commit comments

Comments
 (0)