-
Notifications
You must be signed in to change notification settings - Fork 929
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs: Update contributing and issue template (#2289)
This PR updates contributing and issue template to make easier collaboration. Fixes: #2288 Signed-off-by: Xuewei Niu <justxuewei@apache.org>
- Loading branch information
1 parent
2efc13e
commit e20025a
Showing
3 changed files
with
57 additions
and
84 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,78 +1,53 @@ | ||
Contributing to Dubbogo | ||
# Contributing | ||
|
||
## 1. Branch | ||
## Branch | ||
|
||
>- The name of branches `SHOULD` be in the format of `feature/xxx`. | ||
>- You `SHOULD` checkout a new branch after a feature branch already being merged into upstream, `DO NOT` commit in the old branch. | ||
Our default branch is `main`, which receives new features and bugfixes. Release | ||
branches, e.g. `release-3.0`, will not received new features but bugfixes. | ||
Opening a pull request for the release branches is what we called "backport". | ||
|
||
## 2. Pull Request | ||
## Title | ||
|
||
### 2.1. Title Format | ||
The format of the title of PRs should be: | ||
|
||
The pr head format is `<head> <subject>`. The title should be simpler to show your intent. | ||
|
||
The title format of the pull request `MUST` follow the following rules: | ||
|
||
>- Start with `Doc:` for adding/formatting/improving docs. | ||
>- Start with `Mod:` for formatting codes or adding comment. | ||
>- Start with `Fix:` for fixing bug, and its ending should be ` #issue-id` if being relevant to some issue. | ||
>- Start with `Imp:` for improving performance. | ||
>- Start with `Ftr:` for adding a new feature. | ||
>- Start with `Add:` for adding struct function/member. | ||
>- Start with `Rft:` for refactoring codes. | ||
>- Start with `Tst:` for adding tests. | ||
>- Start with `Dep:` for adding depending libs. | ||
>- Start with `Rem:` for removing feature/struct/function/member/files. | ||
## 3. Code Style | ||
|
||
Please add a blank line at the end of every file. | ||
|
||
Please add a blank line at the sub-title and its content. | ||
|
||
Please add s space between the Engilsh word/digit number and the Chinese character. | ||
|
||
### 3.1 log | ||
|
||
>- 1 when logging the function's input parameter, you should add '@' before input parameter name. | ||
### 3.2 naming | ||
|
||
>- 1 do not use an underscore in package name, such as `filter_impl`. | ||
>- 2 do not use an underscore in constants, such as `DUBBO_PROTOCOL`. use 'DubboProtocol' instead. | ||
### 3.3 comment | ||
``` | ||
<type>: One line summary of the PR | ||
``` | ||
|
||
>- 1 there should be comment for every export func/var. | ||
>- 2 the comment should begin with function name/var name. | ||
The types are including(https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/): | ||
|
||
### 3.4 import | ||
- feat: a new feature is introduced with the changes | ||
- fix: a bug fix has occurred | ||
- chore: changes that do not relate to a fix or feature and don't modify src or test files (for example updating dependencies) | ||
- refactor: refactored code that neither fixes a bug nor adds a feature | ||
- docs: updates to documentation such as a the README or other markdown files | ||
- style: changes that do not affect the meaning of the code, likely related to code formatting such as white-space, missing semi-- - colons, and so on. | ||
- test: including new or correcting previous tests | ||
- perf: performance improvements | ||
- ci: continuous integration related | ||
- build: changes that affect the build system or external dependencies | ||
- revert: reverts a previous commit | ||
|
||
We dubbogo import blocks should be splited into 3 blocks. | ||
If this PR is to backport to other branchs, e.g. `3.0`, then the title would be: | ||
|
||
```Go | ||
// block 1: the go internal package | ||
import ( | ||
"fmt" | ||
) | ||
``` | ||
[3.0] <type>: One line summary of the PR | ||
``` | ||
|
||
// block 2: the third package | ||
import ( | ||
"github.com/dubbogo/xxx" | ||
## Commit message | ||
|
||
"github.com/RoaringBitmap/roaring" | ||
) | ||
Each pull request **MUST** have a corresponding issue to explain what does this PR do. The format of message should be: | ||
|
||
// block 3: the dubbo-go package | ||
import ( | ||
"dubbo.apache.org/dubbo-go/v3/common" | ||
) | ||
``` | ||
(A brief description about this PR.) Lorem ipsum dolor sit amet, consectetur | ||
adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna | ||
aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi | ||
ut aliquip ex ea commodo consequat. | ||
### 3.5 package | ||
|
||
There should be a blank line between the license and the package name. | ||
|
||
The package name should not have "xxx_impl". | ||
Fixes: #1000 | ||
Signed-off-by: Example <example@example.com> | ||
``` | ||
|
||
The signed-off message will be appended automaticaly if the developers commit | ||
with `-s` option, for example, `git commit -s`. |