Skip to content

Commit

Permalink
docs: Update contributing and issue template (#2289)
Browse files Browse the repository at this point in the history
This PR updates contributing and issue template to make easier
collaboration.

Fixes: #2288

Signed-off-by: Xuewei Niu <justxuewei@apache.org>
  • Loading branch information
justxuewei authored Apr 7, 2023
1 parent 2efc13e commit e20025a
Show file tree
Hide file tree
Showing 3 changed files with 57 additions and 84 deletions.
25 changes: 20 additions & 5 deletions .github/ISSUE_TEMPLATE/bug-report.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,15 +5,30 @@ labels: kind/bug

---

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!
### Environment

<!--
- Server: Dubbo-go, v3.0.5
- Client: Dubbo-go, v3.0.5
- Protocol: Triple
- Registry: Nacos, v2.0.0
-->

- Server:
- Client:
- Protocol:
- Registry:

**What happened**:
### Issue description

**What you expected to happen**:
<!-- Here is a brief description about the issue. -->

**How to reproduce it (as minimally and precisely as possible)**:
### Logs

**Anything else we need to know?**:
<details><summary>Click me to check logs</summary>

```
Copy logs to here.
```

</details>
17 changes: 0 additions & 17 deletions .github/PULL_REQUEST_TEMPLATE.md

This file was deleted.

99 changes: 37 additions & 62 deletions CONTRIBUTING.md
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`.

0 comments on commit e20025a

Please sign in to comment.