github.com/cloudwego/kitex@v0.9.0/CONTRIBUTING.md (about) 1 # How to Contribute 2 3 ## Your First Pull Request 4 We use github for our codebase. You can start by reading [How To Pull Request](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests). 5 6 ## Branch Organization 7 We use [git-flow](https://nvie.com/posts/a-successful-git-branching-model/) as our branch organization, as known as [FDD](https://en.wikipedia.org/wiki/Feature-driven_development) 8 9 ## Bugs 10 ### 1. How to Find Known Issues 11 We are using [Github Issues](https://github.com/cloudwego/kitex/issues) for our public bugs. We keep a close eye on this and try to make it clear when we have an internal fix in progress. Before filing a new task, try to make sure your problem doesn't already exist. 12 13 ### 2. Reporting New Issues 14 Providing a reduced test code is a recommended way for reporting issues. Then can placed in: 15 - Just in issues 16 - [Golang Playground](https://play.golang.org/) 17 18 ### 3. Security Bugs 19 Please do not report the safe disclosure of bugs to public issues. Contact us by [Support Email](mailto:conduct@cloudwego.io) 20 21 ## How to Get in Touch 22 - [Email](mailto:conduct@cloudwego.io) 23 24 ## Submit a Pull Request 25 Before you submit your Pull Request (PR) consider the following guidelines: 26 1. Search [GitHub](https://github.com/cloudwego/kitex/pulls) for an open or closed PR that relates to your submission. You don't want to duplicate existing efforts. 27 2. Please submit an issue instead of PR if you have a better suggestion for format tools. We won't accept a lot of file changes directly without issue statement and assignment. 28 3. Be sure that the issue describes the problem you're fixing, or documents the design for the feature you'd like to add. Before we accepting your work, we need to conduct some checks and evaluations. So, It will be better if you can discuss the design with us. 29 4. [Fork](https://docs.github.com/en/github/getting-started-with-github/fork-a-repo) the cloudwego/kitex repo. 30 5. In your forked repository, make your changes in a new git branch: 31 ``` 32 git checkout -b my-fix-branch develop 33 ``` 34 6. Create your patch, including appropriate test cases. Please refer to [Go-UT](https://pkg.go.dev/testing#pkg-overview) for writing guides. [Go-Mock](https://github.com/golang/mock) is recommended to mock interface, please refer to internal/mocks/readme.md for more details, and [Mockey](https://github.com/bytedance/mockey) is recommended to mock functions, please refer to its readme doc for specific usage. 35 7. Follow our [Style Guides](#code-style-guides). 36 8. Commit your changes using a descriptive commit message that follows [AngularJS Git Commit Message Conventions](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit). 37 Adherence to these conventions is necessary because release notes are automatically generated from these messages. 38 9. Push your branch to GitHub: 39 ``` 40 git push origin my-fix-branch 41 ``` 42 10. In GitHub, send a pull request to `kitex:develop` with a clear and unambiguous title. 43 44 ## Contribution Prerequisites 45 - Our development environment keeps up with [Go Official](https://golang.org/project/). 46 - You need fully checking with lint tools before submit your pull request. [gofmt](https://golang.org/pkg/cmd/gofmt/) and [golangci-lint](https://github.com/golangci/golangci-lint) 47 - You are familiar with [Github](https://github.com) 48 - Maybe you need familiar with [Actions](https://github.com/features/actions)(our default workflow tool). 49 50 ## Code Style Guides 51 52 See [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments). 53 54 Good resources: 55 - [Effective Go](https://golang.org/doc/effective_go) 56 - [Pingcap General advice](https://pingcap.github.io/style-guide/general.html) 57 - [Uber Go Style Guide](https://github.com/uber-go/guide/blob/master/style.md)