Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

Commit 79225c1

Browse files
Merge pull request #101 from leapfrogtechnology/feature/pull-request-guidelines
Feature: Addition of pull request guideline page
2 parents 9b788d4 + cf27062 commit 79225c1

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)

AltStyle によって変換されたページ (->オリジナル) /