@@ -14,11 +14,6 @@ considering contributing!
14
14
* [ Issues and Discussions] ( #issues-and-discussions )
15
15
* [ Development Guide] ( #development-guide )
16
16
17
- [ Style Guides] ( #style-guides )
18
-
19
- * [ Git Style Guide] ( #git-style-guide )
20
- * [ Go Style Guide] ( #go-style-guide )
21
-
22
17
[ Code of Conduct] ( CODE_OF_CONDUCT.md )
23
18
24
19
[ Contributor License Agreement] ( #contributor-license-agreement )
@@ -74,8 +69,8 @@ template.
74
69
#### Issue lifecycle
75
70
76
71
When an issue or PR is created, it will be triaged by the maintainers and assigned a label to indicate the type of issue
77
- it is (bug, feature request, etc) and to determine the milestone. See the [ Issue Lifecycle] ( /ISSUE_LIFECYCLE.md ) document
78
- for more information.
72
+ it is (bug, feature request, etc) and to determine the milestone. See the [ Issue Lifecycle] ( /ISSUE_LIFECYCLE.md )
73
+ document for more information.
79
74
80
75
### Development Guide
81
76
@@ -85,36 +80,14 @@ Before beginning development, familiarize yourself with the following documents:
85
80
your development environment and executing tasks required when submitting a pull request.
86
81
- [ Branching and Workflow] ( /docs/developer/branching-and-workflow.md ) : This document outlines the project's specific
87
82
branching and workflow practices, including instructions on how to name a branch.
88
- - [ Implement a Feature] ( /docs/developer/implementing-a-feature.md ) : A step-by-step guide on how to implement a feature or
89
- bug.
83
+ - [ Implement a Feature] ( /docs/developer/implementing-a-feature.md ) : A step-by-step guide on how to implement a feature
84
+ or bug.
90
85
- [ Testing] ( /docs/developer/testing.md ) : The project's testing guidelines, includes both unit testing and manual testing
91
86
procedures. This document explains how to write and run unit tests, and how to manually verify changes.
92
87
- [ Pull Request Guidelines] ( /docs/developer/pull-request.md ) : A guide for both pull request submitters and reviewers,
93
88
outlining guidelines and best practices to ensure smooth and efficient pull request processes.
94
-
95
- ## Style Guides
96
-
97
- ### Git Style Guide
98
-
99
- * Keep a clean, concise and meaningful git commit history on your branch, rebasing locally and squashing before
100
- submitting a PR
101
- * Follow the guidelines of writing a good commit message as described [ here] ( https://chris.beams.io/posts/git-commit/ )
102
- and summarized in the next few points
103
- * In the subject line, use the present tense ("Add feature" not "Added feature")
104
- * In the subject line, use the imperative mood ("Move cursor to..." not "Moves cursor to...")
105
- * Limit the subject line to 72 characters or less
106
- * Reference issues and pull requests liberally after the subject line
107
- * Add more detailed description in the body of the git message (` git commit -a ` to give you more space and time in
108
- your text editor to write a good message instead of ` git commit -am ` )
109
-
110
- ### Go Style Guide
111
-
112
- * Run ` gofmt ` over your code to automatically resolve a lot of style issues. Most editors support this running
113
- automatically when saving a code file.
114
- * Run ` go lint ` and ` go vet ` on your code too to catch any other issues.
115
- * Follow this guide on some good practice and idioms for Go - https://github.com/golang/go/wiki/CodeReviewComments
116
- * To check for extra issues, install [ golangci-lint] ( https://github.com/golangci/golangci-lint ) and run ` make lint `
117
- or ` golangci-lint run `
89
+ - [ Go Style Guide] ( /docs/developer/go-style-guide.md ) A coding style guide for Go. Contains best practices and
90
+ conventions to follow when writing Go code for the project.
118
91
119
92
## Contributor License Agreement
120
93
0 commit comments