Kezdőlap Felfedezés Súgó
Bejelentkezés
malz
/
ekuiper-new
1
0
Másolás 0
Fájlok Problémák 0 Beolvasztási kérések 0 Wiki
Forráskód Böngészése

docs: add roles and responsibilities (#2155)

Signed-off-by: Jiyong Huang <huangjy@emqx.io>
ngjaying 1 éve
szülő
c9750139db
commit
c28a227305
3 módosított fájl, 308 hozzáadás és 62 törlés
Egyesített Nézet Diff Statisztika Mutatása
  1. 83 9
      CONTRIBUTING.md
  2. 164 53
      docs/en_US/CONTRIBUTING.md
  3. 61 0
      docs/zh_CN/CONTRIBUTING.md

+ 83 - 9
CONTRIBUTING.md
Fájl Megtekintése 

@@ -70,8 +70,8 @@ Alternatively, if you use GoLand, you can check `Group` and `Group stdlib import
 
 - Use `go fmt` to format your code before commit code change. eKuiper Github Action CI pipeline reports error if it's
 
 - Use `go fmt` to format your code before commit code change. eKuiper Github Action CI pipeline reports error if it's
 
   not format by `go fmt`.
 
   not format by `go fmt`.
 
 - Run static code analysis with `make lint` to make sure there are no stylistic errors and common programming issues.
 
 - Run static code analysis with `make lint` to make sure there are no stylistic errors and common programming issues.
 
-    - If you encounter lint errors related to `gofumpt`, run `gofumpt -w .` in the project root directory to solve it.
 
-    - Check [golangci-lint](https://golangci-lint.run/) for more information on the corresponding lint errors.
 
+  - If you encounter lint errors related to `gofumpt`, run `gofumpt -w .` in the project root directory to solve it.
 
+  - Check [golangci-lint](https://golangci-lint.run/) for more information on the corresponding lint errors.
 
 - Configuration key in config files uses camel case format.
 
 - Configuration key in config files uses camel case format.
 
 
 
 ### Debug your code
 
 ### Debug your code
 
@@ -206,8 +206,8 @@ The eKuiper project leverages Github actions to run unit test & FVT (functional
 
 look at the PR status result, and make sure that all of testcases run successfully.
 
 look at the PR status result, and make sure that all of testcases run successfully.
 
 
 
 - Write Golang unit testcases to test your code if necessary.
 
 - Write Golang unit testcases to test your code if necessary.
 
-- A set of [FVT testcases](../../test/README.md) will be triggered with any PR submission, so please make sure that
 
-  these
 
+- A set of [FVT testcases](https://github.com/lf-edge/ekuiper/blob/master/test/README.md) will be triggered with any PR
 
+  submission, so please make sure that these
 
   testcases can be run successfully.
 
   testcases can be run successfully.
 
 
 
 ### Licensing
 
 ### Licensing
 
@@ -263,7 +263,7 @@ after all tests passed.
 
 Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes
 
 Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes
 
 a **type**, a **scope** and a **subject**:
 
 a **type**, a **scope** and a **subject**:
 
 
 
-```
 
+```text
 
 <type>(<scope>): <subject>
 
 <type>(<scope>): <subject>
 
 <BLANK LINE>
 
 <BLANK LINE>
 
 <body>
 
 <body>
 
@@ -282,11 +282,11 @@ a [closing reference to an issue](https://help.github.com/articles/closing-issue
 
 
 
 Example 1:
 
 Example 1:
 
 
 
-```
 
+```text
 
 feat: add Fuji release compose files
 
 feat: add Fuji release compose files
 
 ```
 
 ```
 
 
 
-```
 
+```text
 
 fix(script): correct run script to use the right ports
 
 fix(script): correct run script to use the right ports
 
 
 
 Previously device services used wrong port numbers. This commit fixes the port numbers to use the latest port numbers.
 
 Previously device services used wrong port numbers. This commit fixes the port numbers to use the latest port numbers.
 
@@ -351,7 +351,81 @@ The promotion contributions include but not limit to:
 
 - Integrate of eKuiper to your open source project
 
 - Integrate of eKuiper to your open source project
 
 - Organize workshops or meetups about the project
 
 - Organize workshops or meetups about the project
 
 - Answer questions about the project on issues, slack or maillist
 
 - Answer questions about the project on issues, slack or maillist
 
-- Write tutorials for how project can be used
 
+- Write tutorials for how a project can be used
 
 - Offer to mentor another contributor
 
 - Offer to mentor another contributor
 
 
 
-Thank you for taking the time to contribute!
 
+Thank you for taking the time to contribute!
 
+
 
+## Roles and responsibilities
 
+
 
+### Contributor
 
+
 
+Contributors are community members who contribute in concrete ways to the project.
 
+Anyone can contribute to the project and become a contributor, regardless of their skillset.
 
+There is no expectation of commitment to the project, no specific skill requirements, and no selection process.
 
+There are many ways to contribute to the project, which may be one or more of the following (but not limited to):
 
+
 
+- Reporting or fixing bugs.
 
+- Identifying requirements, strengths, and weaknesses.
 
+- Writing documentation.
 
+
 
+For first-time contributors,
 
+it is recommended to start by going through [code and doc contribution](#code-and-doc-contribution),
 
+and joining our community Slack channel.
 
+
 
+As one continues to contribute to the project and engage with the community,
 
+he/she may at some point become eligible for an eKuiper committer.
 
+
 
+### Committer
 
+
 
+Committers are active community members who have shown that they are committed to the continuous development of the
 
+project through ongoing engagement with the community.
 
+Committership allows contributors to more easily carry on with their project-related activities by giving them direct
 
+access to the project’s resources.
 
+
 
+Typically, a potential committer needs to show that they have a sufficient understanding of the project, its objectives,
 
+and its strategy. To become a committer, you are expected to:
 
+
 
+- Be a eKuiper contributor.
 
+- Express interest to the existing maintainers that you are interested in becoming a committer.
 
+- Have contributed 6 or more substantial PRs.
 
+- Have an above-average understanding of the project codebase, its goals, and directions.
 
+
 
+Contributors that meet the above requirements will be nominated by an existing maintainer to become a committer. It is
 
+recommended to describe the reasons for the nomination and the contribution of the nominee in the PR. The existing
 
+maintainers will confer and decide whether to grant committer status or not.
 
+
 
+Committers are expected to review issues and PRs. Their LGTM counts towards the required LGTM count to merge a PR. While
 
+committership indicates a valued member of the community who has demonstrated a healthy respect for the project’s aims
 
+and objectives, their work continues to be reviewed by the community before acceptance in an official release.
 
+
 
+A committer who shows an above-average level of contribution to the project, particularly with respect to its strategic
 
+direction and long-term health, may be nominated to become a maintainer. This role is described below.
 
+
 
+### Maintainer
 
+
 
+Maintainers are first and foremost committers that have shown they are committed to the long term success of a project.
 
+They are the planners and designers of the eKuiper project.
 
+Maintainership is about building trust with the current maintainers of the project and being a person that they can
 
+depend on to make decisions in the best interest of the project in a consistent manner.
 
+
 
+Committers want to become maintainers are expected to:
 
+
 
+- Enable adoptions or ecosystems.
 
+- Collaborate well. Participate in community meetings and events.
 
+- Demonstrate a deep and comprehensive understanding of eKuiper's architecture, technical goals, and directions.
 
+- Actively engage with major eKuiper feature proposals and implementations.
 
+
 
+A new maintainer must be nominated by an existing maintainer. The nominating maintainer will create a PR to update
 
+the [Maintainer List](https://github.com/lf-edge/ekuiper/blob/master/MAINTAINERS.md). It is recommended to describe the
 
+reasons for the nomination and the contribution of the nominee in the PR. Upon consensus of incumbent maintainers, the
 
+PR will be approved and the new maintainer becomes active.
 
+
 
+### Nomination process
 
+
 
+The following table describes how the nomination is approved.
 
+
 
+| Nomination     | Description                                                                  | Approval                                                              | Binding Roles      | Minimum Length (days) |
 
+|:---------------|:-----------------------------------------------------------------------------|:----------------------------------------------------------------------|:-------------------|:----------------------|
 
+| New Committer  | When a new committer is proposed, should be only nominated by a maintainer.  | [Lazy Consensus](https://communitymgt.fandom.com/wiki/Lazy_consensus) | Active maintainers | 7                     |
 
+| New Maintainer | When a new maintainer is proposed, should be only nominated by a maintainer. | Supermajority (2/3) Approval                                          | Active maintainers | 7                     |

+ 164 - 53
docs/en_US/CONTRIBUTING.md
Fájl Megtekintése 

@@ -4,8 +4,12 @@ We're really glad you're reading this, because we need volunteer developers to h
 
 
 
 ## Did you find a bug?
 
 ## Did you find a bug?
 
 
 
-- **Ensure the bug was not already reported** by searching on GitHub under [Issues](https://github.com/lf-edge/ekuiper/issues).
 
-- If you're unable to find an open issue addressing the problem, [open a new one](https://github.com/lf-edge/ekuiper/issues/new). Be sure to include a **title and clear description**, as much relevant information as possible, and a **code sample** or an **executable test case** demonstrating the expected behavior that is not occurring.
 
+- **Ensure the bug was not already reported** by searching on GitHub
 
+  under [Issues](https://github.com/lf-edge/ekuiper/issues).
 
+- If you're unable to find an open issue addressing the
 
+  problem, [open a new one](https://github.com/lf-edge/ekuiper/issues/new). Be sure to include a **title and clear
 
+  description**, as much relevant information as possible, and a **code sample** or an **executable test case**
 
+  demonstrating the expected behavior that is not occurring.
 
 
 
 ## Code and doc contribution
 
 ## Code and doc contribution
 
 
 
@@ -13,7 +17,8 @@ Welcome to contribute code to provide features or fix bugs.
 
 
 
 ### One time setup
 
 ### One time setup
 
 
 
-We use GitHub pull request to review proposed code changes. So you'll need to obtain a GitHub account before making code contribution.
 
+We use GitHub pull request to review proposed code changes. So you'll need to obtain a GitHub account before making code
 
+contribution.
 
 
 
 1. **Fork** eKuiper to your private repository. Click the `Fork` button in the top right corner of eKuiper repository.
 
 1. **Fork** eKuiper to your private repository. Click the `Fork` button in the top right corner of eKuiper repository.
 
 2. **Clone** the repository locally from your personal fork. `git clone https://github.com/<Github_user>/ekuiper.git`.
 
 2. **Clone** the repository locally from your personal fork. `git clone https://github.com/<Github_user>/ekuiper.git`.
 
@@ -23,11 +28,14 @@ We use GitHub pull request to review proposed code changes. So you'll need to ob
 
   git remote add upstream https://github.com/lf-edge/ekuiper.git
 
   git remote add upstream https://github.com/lf-edge/ekuiper.git
 
   ```
 
   ```
 
 
 
-You can use your favorite IDE or editor to develop. You can find information in editor support for Go tools in [Editors and IDEs for GO](https://github.com/golang/go/wiki/IDEsAndTextEditorPlugins).
 
+You can use your favorite IDE or editor to develop. You can find information in editor support for Go tools
 
+in [Editors and IDEs for GO](https://github.com/golang/go/wiki/IDEsAndTextEditorPlugins).
 
 
 
 ### Create a branch in your fork
 
 ### Create a branch in your fork
 
 
 
-You’ll work on your contribution in a branch in your own (forked) repository. Create a local branch, initialized with the state of the branch you expect your changes to be merged into. The `master` branch is active development branch, so it's recommended to set `master` as base branch.
 
+You’ll work on your contribution in a branch in your own (forked) repository. Create a local branch, initialized with
 
+the state of the branch you expect your changes to be merged into. The `master` branch is active development branch, so
 
+it's recommended to set `master` as base branch.
 
 
 
 ```shell
 
 ```shell
 
 $ git fetch upstream
 
 $ git fetch upstream
 
@@ -50,7 +58,8 @@ import (
 
 )
 
 )
 
 ```
 
 ```
 
 
 
-In the project root directory, you can run the command `gci write --skip-generated -s standard -s default -s "prefix(github.com/lf-edge/ekuiper)" .` to
 
+In the project root directory, you can run the
 
+command `gci write --skip-generated -s standard -s default -s "prefix(github.com/lf-edge/ekuiper)" .` to
 
 automatically reorder package imports.
 
 automatically reorder package imports.
 
 
 
 Alternatively, if you use GoLand, you can check `Group` and `Group stdlib imports` as well as their sub-options under
 
 Alternatively, if you use GoLand, you can check `Group` and `Group stdlib imports` as well as their sub-options under
 
@@ -69,45 +78,53 @@ Alternatively, if you use GoLand, you can check `Group` and `Group stdlib import
 
 
 
 Take GoLand as an example, developers can debug the code:
 
 Take GoLand as an example, developers can debug the code:
 
 
 
-1. Debug the whole program. Make sure all directories mentioned in [Makefile](https://github.com/lf-edge/ekuiper/blob/master/Makefile) build_prepare sections are created in your eKuiper root path. Add your breakpoints. Open `cmd/kuiperd/main.go`. In the main function, you'll find a green triangle in the ruler, click it and select debug. Then create your stream/rule that would run through your breakpoint, the debugger will pause there.
 
-2. To debug a small portion of code, we recommend writing a unit test and debug it. You can go to any test file and find the same green triangle to run in debug mode. For example, `pkg/cast/cast_test.go` TestMapConvert_Funcs can run as debug.
 
+1. Debug the whole program. Make sure all directories mentioned
 
+   in [Makefile](https://github.com/lf-edge/ekuiper/blob/master/Makefile) build_prepare sections are created in your
 
+   eKuiper root path. Add your breakpoints. Open `cmd/kuiperd/main.go`. In the main function, you'll find a green
 
+   triangle in the ruler, click it and select debug. Then create your stream/rule that would run through your
 
+   breakpoint, the debugger will pause there.
 
+2. To debug a small portion of code, we recommend writing a unit test and debug it. You can go to any test file and find
 
+   the same green triangle to run in debug mode. For example, `pkg/cast/cast_test.go` TestMapConvert_Funcs can run as
 
+   debug.
 
 
 
 #### Debug edgex code
 
 #### Debug edgex code
 
 
 
-Users can modify edgex source/sink code to meet their requirement. In this case, the best practice is letting the other services running in docker mode but eKuiper run locally.
 
+Users can modify edgex source/sink code to meet their requirement. In this case, the best practice is letting the other
 
+services running in docker mode but eKuiper run locally.
 
 Users can follow these steps to set up the environment.
 
 Users can follow these steps to set up the environment.
 
 
 
 #### expose message bus
 
 #### expose message bus
 
 
 
-  eKuiper subscribe messages by topic and by default edgex is using redis as message bus. This guide will use redis as example to show how to expose message bus.
 
-  In the docker-compose file, find the redis service and in ports part change 127.0.0.1:6379
 
+eKuiper subscribe messages by topic and by default edgex is using redis as message bus. This guide will use redis as
 
+example to show how to expose message bus.
 
+In the docker-compose file, find the redis service and in ports part change 127.0.0.1:6379
 
 to 0.0.0.0:6379, then restart all the services.
 
 to 0.0.0.0:6379, then restart all the services.
 
 
 
 ```yaml
 
 ```yaml
 
  database:
 
  database:
 
-    container_name: edgex-redis
 
-    environment:
 
-      CLIENTS_CORE_COMMAND_HOST: edgex-core-command
 
-      CLIENTS_CORE_DATA_HOST: edgex-core-data
 
-      CLIENTS_CORE_METADATA_HOST: edgex-core-metadata
 
-      CLIENTS_SUPPORT_NOTIFICATIONS_HOST: edgex-support-notifications
 
-      CLIENTS_SUPPORT_SCHEDULER_HOST: edgex-support-scheduler
 
-      DATABASES_PRIMARY_HOST: edgex-redis
 
-      EDGEX_SECURITY_SECRET_STORE: "false"
 
-      REGISTRY_HOST: edgex-core-consul
 
-    hostname: edgex-redis
 
-    image: redis:6.2-alpine
 
-    networks:
 
-      edgex-network: {}
 
-    ports:
 
-    - 0.0.0.0:6379:6379/tcp
 
-    read_only: true
 
-    restart: always
 
-    security_opt:
 
-    - no-new-privileges:true
 
-    user: root:root
 
-    volumes:
 
-    - db-data:/data:z
 
+   container_name: edgex-redis
 
+   environment:
 
+     CLIENTS_CORE_COMMAND_HOST: edgex-core-command
 
+     CLIENTS_CORE_DATA_HOST: edgex-core-data
 
+     CLIENTS_CORE_METADATA_HOST: edgex-core-metadata
 
+     CLIENTS_SUPPORT_NOTIFICATIONS_HOST: edgex-support-notifications
 
+     CLIENTS_SUPPORT_SCHEDULER_HOST: edgex-support-scheduler
 
+     DATABASES_PRIMARY_HOST: edgex-redis
 
+     EDGEX_SECURITY_SECRET_STORE: "false"
 
+     REGISTRY_HOST: edgex-core-consul
 
+   hostname: edgex-redis
 
+   image: redis:6.2-alpine
 
+   networks:
 
+     edgex-network: { }
 
+   ports:
 
+     - 0.0.0.0:6379:6379/tcp
 
+   read_only: true
 
+   restart: always
 
+   security_opt:
 
+     - no-new-privileges:true
 
+   user: root:root
 
+   volumes:
 
+     - db-data:/data:z
 
 
 
 ```
 
 ```
 
 
 
@@ -137,7 +154,8 @@ default:
 
   messageType: event
 
   messageType: event
 
 ```
 
 ```
 
 
 
-After changing this, redis will listen on the host 6379 port, developers can connect to the machine that edgex runs remotely by the server address.
 
+After changing this, redis will listen on the host 6379 port, developers can connect to the machine that edgex runs
 
+remotely by the server address.
 
 For example, the host ip address is 10.65.38.224 , users can connect to this machine by the ip address.
 
 For example, the host ip address is 10.65.38.224 , users can connect to this machine by the ip address.
 
 
 
 #### enable eKuiper console log and set rest api port
 
 #### enable eKuiper console log and set rest api port
 
@@ -180,7 +198,7 @@ basic:
 
 
 
 #### run locally
 
 #### run locally
 
 
 
-  Use the [former method](./CONTRIBUTING.md#debug-your-code) to run the eKuiper
 
+Use the [former method](./CONTRIBUTING.md#debug-your-code) to run the eKuiper
 
 
 
 ### Testing
 
 ### Testing
 
 
 
@@ -188,28 +206,33 @@ The eKuiper project leverages Github actions to run unit test & FVT (functional
 
 look at the PR status result, and make sure that all of testcases run successfully.
 
 look at the PR status result, and make sure that all of testcases run successfully.
 
 
 
 - Write Golang unit testcases to test your code if necessary.
 
 - Write Golang unit testcases to test your code if necessary.
 
-- A set of [FVT testcases](../../test/README.md) will be triggered with any PR submission, so please make sure that these
 
+- A set of [FVT testcases](https://github.com/lf-edge/ekuiper/blob/master/test/README.md) will be triggered with any PR
 
+  submission, so please make sure that these
 
   testcases can be run successfully.
 
   testcases can be run successfully.
 
 
 
 ### Licensing
 
 ### Licensing
 
 
 
-All code contributed to eKuiper will be licensed under Apache License V2. You need to ensure every new files you are adding have the right license header.
 
+All code contributed to eKuiper will be licensed under Apache License V2. You need to ensure every new files you are
 
+adding have the right license header.
 
 
 
 ### Sign-off commit
 
 ### Sign-off commit
 
 
 
 The sign-off is to certify the origin of the commit. It is required to commit to this project. If you set
 
 The sign-off is to certify the origin of the commit. It is required to commit to this project. If you set
 
-your `user.name` and `user.email` git configs, you can sign your commit automatically with `git commit -s`. Each commit must be signed off.
 
+your `user.name` and `user.email` git configs, you can sign your commit automatically with `git commit -s`. Each commit
 
+must be signed off.
 
 
 
 ### Syncing
 
 ### Syncing
 
 
 
-Periodically while you work, and certainly before submitting a pull request, you should update your branch with the most recent changes to the target branch. We prefer rebase than merge to avoid extraneous merge commits.
 
+Periodically while you work, and certainly before submitting a pull request, you should update your branch with the most
 
+recent changes to the target branch. We prefer rebase than merge to avoid extraneous merge commits.
 
 
 
 ```shell
 
 ```shell
 
 git fetch upstream
 
 git fetch upstream
 
 git rebase upstream/master
 
 git rebase upstream/master
 
 ```
 
 ```
 
 
 
-Then you can push to your forked repo. Assume the remove name for your forked is the default `origin`. If you have rebased the git history before the last push, add `-f` to force pushing the changes.
 
+Then you can push to your forked repo. Assume the remove name for your forked is the default `origin`. If you have
 
+rebased the git history before the last push, add `-f` to force pushing the changes.
 
 
 
 ```shell
 
 ```shell
 
 git push origin -f
 
 git push origin -f
 
@@ -220,7 +243,10 @@ git push origin -f
 
 The `master` branch is active development branch, so it's recommended to set `master` as base branch, and also create PR
 
 The `master` branch is active development branch, so it's recommended to set `master` as base branch, and also create PR
 
 against `master` branch.
 
 against `master` branch.
 
 
 
-Organize your commits to make a committer’s job easier when reviewing. Committers normally prefer multiple small pull requests, instead of a single large pull request. Within a pull request, a relatively small number of commits that break the problem into logical steps is preferred. For most pull requests, you'll squash your changes down to 1 commit. You can use the following command to re-order, squash, edit, or change description of individual commits.
 
+Organize your commits to make a committer’s job easier when reviewing. Committers normally prefer multiple small pull
 
+requests, instead of a single large pull request. Within a pull request, a relatively small number of commits that break
 
+the problem into logical steps is preferred. For most pull requests, you'll squash your changes down to 1 commit. You
 
+can use the following command to re-order, squash, edit, or change description of individual commits.
 
 
 
 ```shell
 
 ```shell
 
 git rebase -i upstream/master
 
 git rebase -i upstream/master
 
@@ -228,11 +254,14 @@ git rebase -i upstream/master
 
 
 
 Make sure all your commits comply to the [commit message guidelines](#commit-message-guidelines).
 
 Make sure all your commits comply to the [commit message guidelines](#commit-message-guidelines).
 
 
 
-You'll then push to your branch on your forked repo and then navigate to eKuiper repo to create a pull request. Our GitHub repo provides automatic testing with GitHub action. Please make sure those tests pass. We will review the code after all tests passed.
 
+You'll then push to your branch on your forked repo and then navigate to eKuiper repo to create a pull request. Our
 
+GitHub repo provides automatic testing with GitHub action. Please make sure those tests pass. We will review the code
 
+after all tests passed.
 
 
 
 ### Commit Message Guidelines
 
 ### Commit Message Guidelines
 
 
 
-Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, a **scope** and a **subject**:
 
+Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes
 
+a **type**, a **scope** and a **subject**:
 
 
 
 ```text
 
 ```text
 
 <type>(<scope>): <subject>
 
 <type>(<scope>): <subject>
 
@@ -242,11 +271,14 @@ Each commit message consists of a **header**, a **body** and a **footer**. The h
 
 <footer>
 
 <footer>
 
 ```
 
 ```
 
 
 
-The **header** with **type** is mandatory. The **scope** of the header is optional. This repository has no predefined scopes. A custom scope can be used for clarity if desired.
 
+The **header** with **type** is mandatory. The **scope** of the header is optional. This repository has no predefined
 
+scopes. A custom scope can be used for clarity if desired.
 
 
 
-Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.
 
+Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub
 
+as well as in various git tools.
 
 
 
-The footer should contain a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages/) if any.
 
+The footer should contain
 
+a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages/) if any.
 
 
 
 Example 1:
 
 Example 1:
 
 
 
@@ -264,7 +296,8 @@ Closes: #123, #245, #992
 
 
 
 #### Revert
 
 #### Revert
 
 
 
-If the commit reverts a previous commit, it should begin with `revert:`, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
 
+If the commit reverts a previous commit, it should begin with `revert:`, followed by the header of the reverted commit.
 
+In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
 
 
 
 #### Type
 
 #### Type
 
 
 
@@ -278,7 +311,8 @@ Must be one of the following:
 
 - **chore**: Updating grunt tasks etc; no production code change
 
 - **chore**: Updating grunt tasks etc; no production code change
 
 - **perf**: A code change that improves performance
 
 - **perf**: A code change that improves performance
 
 - **test**: Adding missing tests, refactoring tests; no production code change
 
 - **test**: Adding missing tests, refactoring tests; no production code change
 
-- **build**: Changes that affect the CI/CD pipeline or build system or external dependencies (example scopes: travis, jenkins, makefile)
 
+- **build**: Changes that affect the CI/CD pipeline or build system or external dependencies (example scopes: travis,
 
+  jenkins, makefile)
 
 - **ci**: Changes provided by DevOps for CI purposes.
 
 - **ci**: Changes provided by DevOps for CI purposes.
 
 - **revert**: Reverts a previous commit.
 
 - **revert**: Reverts a previous commit.
 
 
 
@@ -296,13 +330,16 @@ The subject contains a succinct description of the change:
 
 
 
 #### Body
 
 #### Body
 
 
 
-Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
 
+Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes". The body should
 
+include the motivation for the change and contrast this with previous behavior.
 
 
 
 #### Footer
 
 #### Footer
 
 
 
-The footer should contain any information about **Breaking Changes** and is also the place to reference GitHub issues that this commit **Closes**.
 
+The footer should contain any information about **Breaking Changes** and is also the place to reference GitHub issues
 
+that this commit **Closes**.
 
 
 
-**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this.
 
+**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit
 
+message is then used for this.
 
 
 
 ## Community Promotion
 
 ## Community Promotion
 
 
 
@@ -314,7 +351,81 @@ The promotion contributions include but not limit to:
 
 - Integrate of eKuiper to your open source project
 
 - Integrate of eKuiper to your open source project
 
 - Organize workshops or meetups about the project
 
 - Organize workshops or meetups about the project
 
 - Answer questions about the project on issues, slack or maillist
 
 - Answer questions about the project on issues, slack or maillist
 
-- Write tutorials for how project can be used
 
+- Write tutorials for how a project can be used
 
 - Offer to mentor another contributor
 
 - Offer to mentor another contributor
 
 
 
 Thank you for taking the time to contribute!
 
 Thank you for taking the time to contribute!
 
+
 
+## Roles and responsibilities
 
+
 
+### Contributor
 
+
 
+Contributors are community members who contribute in concrete ways to the project.
 
+Anyone can contribute to the project and become a contributor, regardless of their skillset.
 
+There is no expectation of commitment to the project, no specific skill requirements, and no selection process.
 
+There are many ways to contribute to the project, which may be one or more of the following (but not limited to):
 
+
 
+- Reporting or fixing bugs.
 
+- Identifying requirements, strengths, and weaknesses.
 
+- Writing documentation.
 
+
 
+For first-time contributors,
 
+it is recommended to start by going through [code and doc contribution](#code-and-doc-contribution),
 
+and joining our community Slack channel.
 
+
 
+As one continues to contribute to the project and engage with the community,
 
+he/she may at some point become eligible for an eKuiper committer.
 
+
 
+### Committer
 
+
 
+Committers are active community members who have shown that they are committed to the continuous development of the
 
+project through ongoing engagement with the community.
 
+Committership allows contributors to more easily carry on with their project-related activities by giving them direct
 
+access to the project’s resources.
 
+
 
+Typically, a potential committer needs to show that they have a sufficient understanding of the project, its objectives,
 
+and its strategy. To become a committer, you are expected to:
 
+
 
+- Be a eKuiper contributor.
 
+- Express interest to the existing maintainers that you are interested in becoming a committer.
 
+- Have contributed 6 or more substantial PRs.
 
+- Have an above-average understanding of the project codebase, its goals, and directions.
 
+
 
+Contributors that meet the above requirements will be nominated by an existing maintainer to become a committer. It is
 
+recommended to describe the reasons for the nomination and the contribution of the nominee in the PR. The existing
 
+maintainers will confer and decide whether to grant committer status or not.
 
+
 
+Committers are expected to review issues and PRs. Their LGTM counts towards the required LGTM count to merge a PR. While
 
+committership indicates a valued member of the community who has demonstrated a healthy respect for the project’s aims
 
+and objectives, their work continues to be reviewed by the community before acceptance in an official release.
 
+
 
+A committer who shows an above-average level of contribution to the project, particularly with respect to its strategic
 
+direction and long-term health, may be nominated to become a maintainer. This role is described below.
 
+
 
+### Maintainer
 
+
 
+Maintainers are first and foremost committers that have shown they are committed to the long term success of a project.
 
+They are the planners and designers of the eKuiper project.
 
+Maintainership is about building trust with the current maintainers of the project and being a person that they can
 
+depend on to make decisions in the best interest of the project in a consistent manner.
 
+
 
+Committers want to become maintainers are expected to:
 
+
 
+- Enable adoptions or ecosystems.
 
+- Collaborate well. Participate in community meetings and events.
 
+- Demonstrate a deep and comprehensive understanding of eKuiper's architecture, technical goals, and directions.
 
+- Actively engage with major eKuiper feature proposals and implementations.
 
+
 
+A new maintainer must be nominated by an existing maintainer. The nominating maintainer will create a PR to update
 
+the [Maintainer List](https://github.com/lf-edge/ekuiper/blob/master/MAINTAINERS.md). It is recommended to describe the
 
+reasons for the nomination and the contribution of the nominee in the PR. Upon consensus of incumbent maintainers, the
 
+PR will be approved and the new maintainer becomes active.
 
+
 
+### Nomination process
 
+
 
+The following table describes how the nomination is approved.
 
+
 
+| Nomination     | Description                                                                  | Approval                                                              | Binding Roles      | Minimum Length (days) |
 
+|:---------------|:-----------------------------------------------------------------------------|:----------------------------------------------------------------------|:-------------------|:----------------------|
 
+| New Committer  | When a new committer is proposed, should be only nominated by a maintainer.  | [Lazy Consensus](https://communitymgt.fandom.com/wiki/Lazy_consensus) | Active maintainers | 7                     |
 
+| New Maintainer | When a new maintainer is proposed, should be only nominated by a maintainer. | Supermajority (2/3) Approval                                          | Active maintainers | 7                     |

+ 61 - 0
docs/zh_CN/CONTRIBUTING.md
Fájl Megtekintése 

@@ -310,3 +310,64 @@ Closes: #123, #245, #992
 
 - 为其他贡献者提供指导
 
 - 为其他贡献者提供指导
 
 
 
 感谢你的贡献！
 
 感谢你的贡献！
 
+
 
+## 角色和职责
 
+
 
+### 贡献者
 
+
 
+贡献者是以具体方式为项目做出贡献的社区成员。任何人都可以为项目做出贡献并成为贡献者。没有对项目承诺的期望，没有特定的技能要求，也没有筛选过程。
 
+为项目做出贡献的方式有很多，可以是以下一种或多种（但不限于）：
 
+
 
+- 报告或修复错误。
 
+- 确定需求、优势和劣势。
 
+- 撰写文档。
 
+
 
+对于首次贡献者
 
+建议先阅读[代码和文档贡献](#代码和文档贡献)、并加入我们的社区 Slack 频道。
 
+
 
+随着贡献者不断为项目做出贡献并参与社区活动，他/她就有资格成为项目的 Committer 。
 
+
 
+### Committer
 
+
 
+Committer 是活跃的社区成员，他们通过与社区的持续互动，表明自己致力于项目的持续发展。
 
+Committer 可以直接访问项目资源，从而更轻松地开展与项目相关的活动。
 
+
 
+通常情况下，有意向成为提交者的贡献者需要证明他们对项目、项目目标和项目战略有足够的了解。要成为 Committer ，您需要具备以下条件
 
+
 
+- 是 eKuiper 的贡献者。
 
+- 向现有的维护者表示有兴趣成为 Committer。
 
+- 贡献过 6 个或更多 PR。
 
+- 对项目代码库、目标和方向有超出平均水平的理解。
 
+
 
+符合上述要求的贡献者将由现有维护者提名成为 Committer。建议在 PR 中说明提名原因和被提名者的贡献。现有维护者将商议并决定是否授予
 
+Committer 身份。
 
+
 
+Committer 应审核问题和 PR。他们的 LGTM 计数将计入合并 PR 所需的 LGTM 计数。
 
+虽然 Committer 身份表明他们是社区的重要成员，他们的工作在正式合并前仍需由社区审核。
 
+
 
+Committer 对项目的贡献超过平均水平，特别是在项目的战略方向和长期健康方面做出了超过平均水平的贡献，可以被提名为维护者。
 
+
 
+### 维护者
 
+
 
+维护者首先是 Committer ，他们已证明自己致力于项目的长期成功。他们是 eKuiper 项目的规划者和设计者。
 
+维护者的职责是与当前项目的维护者建立信任，并成为他们可以信赖的人，能够始终如一地做出符合项目最佳利益的决策。
 
+
 
+希望成为维护者的提交者应做到以下几点：
 
+
 
+- 促进项目采用率或生态系统。
 
+- 善于协作，参与社区会议和活动。
 
+- 深入全面地了解 eKuiper 的架构、技术目标和发展方向。
 
+- 积极参与主要的 eKuiper 功能提案和实施。
 
+
 
+新维护者必须由现有维护者提名。提名维护者将创建一份
 
+PR，以更新[维护者列表](https://github.com/lf-edge/ekuiper/blob/master/MAINTAINERS.md)。建议描述
 
+被提名者的贡献。在现任维护者达成共识后，PR 将被批准，新的维护者将成为活跃维护者。
 
+
 
+### 提名流程
 
+
 
+下表描述了如何批准提名。
 
+
 
+| 提名          | 说明       | 批准流程                                                                  | 约束角色  | 最短期限（天） |
 
+|:------------|:---------|:----------------------------------------------------------------------|:------|:--------|
 
+| 新 Committer | 只能由维护者提名 | [Lazy Consensus](https://communitymgt.fandom.com/wiki/Lazy_consensus) | 活跃维护者 | 7       |
 
+| 新维护者        | 只能由维护者提名 | 2/3 投票通过                                                              | 活跃维护者 | 7       |