aesthetic changes

Author: mesaugat

docs/git/pull-request-guidelines.md

@@ -3,10 +3,8 @@ id: pull-request-guidelines
 title: Pull Request Guidelines
 ---
 
-
 # Generic Pull Request Guidelines
 
-
 ## Consider the following points while submitting and reviewing a pull request.
 
 **1. Small and focused changes:** Break down the code into small and manageable units. 
@@ -24,12 +22,8 @@ title: Pull Request Guidelines
 
 **7. Follow PR standard practices:** Use clear and descriptive titles. Provide detailed description of the changes and include screenshots and documentations.
 
-
-
 ## Reviewers Guideline
 
-
-
 * Open Mindset
     * Acceptive
     * Open to enhancements/improvements
@@ -40,19 +34,18 @@ title: Pull Request Guidelines
 * Be polite and respectful
 * Don’t just comment for the sake of it
 
-## Additional Role of TL
+## Additional Role of Team Leads and Code Owners
+
 **1. Performance and Scalability:** Consider the performance implications of the code changes. Assess whether the code might introduce bottlenecks or negatively impact system performance. Ensure that scalability concerns are addressed if applicable.
 
-**2. Feature breakdown:** Make sure the features and PR are broken into meaningful chunks during sprint planning.
+**2. Feature Breakdown:** Make sure the features and PR are broken into meaningful chunks during sprint planning.
 
 **3. Architecture and Design:** Check if the code changes align with the overall system architecture and design. Ensure that the proposed changes fit into the existing structure and don't introduce architectural conflicts.
 
-**4. Repository maintainer:** Ultimately, the team lead may need to make a decision on whether to approve, request changes, or reject the PR. This decision should be based on the code's quality, alignment with project goals, and any necessary improvements.
-
-
-## Things to keep in mind
+**4. Ownership:** Ultimately, the code owner or a team lead may need to make a decision on whether to approve, request changes, or reject the PR. This decision should be based on the code's quality, alignment with project goals, and any necessary improvements.
 
 
+## Things to Keep in Mind
 
 1. Granularization of tasks
     1. Small biteable size of code
@@ -61,36 +54,33 @@ title: Pull Request Guidelines
         3. Easy comprehension
 2. Learning process for the reviewer and reviewee
 3. Alignment to git strategy
-    2. [Git flow](https://danielkummer.github.io/git-flow-cheatsheet/)
-4. [Clean Code](https://github.com/SaikrishnaReddy1919/MyBooks/blob/master/%5BPROGRAMMING%5D%5BClean%20Code%20by%20Robert%20C%20Martin%5D.pdf)
-5. Strictly follow design principles.
-    3. DRY
-    4. KISS
-    5. YAGNI
-    6. SOLID
-6. Conventions
-    7. [Naming conventions](https://github.com/kettanaito/naming-cheatsheet)
-7. Proper Use of inbuilt functions
-    8. Only wrap exceptional logic in try catch.
-    9. Avoid unnecessary else statements.
-    10. Consistent return
-8. Use of Packages
-    11. After a brief consultation with application team members.
-    12. Freeze package names for major versions
-9. Keep an eye out for functional and object-oriented concepts.
-10. Component-based development
-    13. Use of non unique ids. Component composition rule violation.
-    14. Keep reusability in mind
-    15. Avoid side effects
-    16. Schema driven development
-
-
-## Pull request description
+    * [Git flow](https://danielkummer.github.io/git-flow-cheatsheet/)
+5. [Clean Code](https://github.com/SaikrishnaReddy1919/MyBooks/blob/master/%5BPROGRAMMING%5D%5BClean%20Code%20by%20Robert%20C%20Martin%5D.pdf)
+6. Strictly follow design principles.
+    * DRY
+    * KISS
+    * YAGNI
+    * SOLID
+7. Conventions
+    * [Naming conventions](https://github.com/kettanaito/naming-cheatsheet)
+8. Proper Use of inbuilt functions
+    * Only wrap exceptional logic in try catch
+    * Avoid unnecessary else statements
+    * Consistent return
+9. Use of Packages
+    * Consult your team to decide if a package is feasible for the project
+    * Freeze package names for major versions
+10. Keep an eye out for functional and object-oriented concepts.
+11. Component-based development
+    * Use of non unique ids. Component composition rule violation.
+    * Keep reusability in mind
+    * Avoid side effects
+    * Schema driven development
+
+## Pull Request Description
 
 Please note a few things while opening your PRs. Add the following things to your PR's description.
 
-
-
 * Description - A short description of the feature for which the PR is opened.
 * Summary of changes - Changes in the source code which the PR comprises.
 * Route - The route from where we can view the feature being added in this PR.
@@ -99,7 +89,7 @@ Please note a few things while opening your PRs. Add the following things to you
 
 Also, make sure to add some reviewers and assign yourself as an Assignee.
 
-#### Best Practices:
+### Best Practices:
 
 * Pull Request should atleast be <b>reviewed by 1 person</b> before merging it to the base branch.
 * Only comment author can resolve comment – if code was corrected or after discussion author decides to fix it.
@@ -109,9 +99,6 @@ Also, make sure to add some reviewers and assign yourself as an Assignee.
 * Use labels to mark what actions should be next – e.g. `needs review`, `Reviewed By... ` etc.
 * Provide details/screenshots about what has been changed.
 
-References
-
-
+### References
 
-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)
-2. [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)
+* [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)