This is an automated email from the ASF dual-hosted git repository.
peacewong pushed a commit to branch dev
in repository https://gitbox.apache.org/repos/asf/incubator-linkis-website.git
The following commit(s) were added to refs/heads/dev by this push:
new 9109db8 modify how to contribute
new 8143797 Merge pull request #48 from casionone/dev
9109db8 is described below
commit 9109db8dd5c8082d519209e9a95574944abab770
Author: casionone <[email protected]>
AuthorDate: Sun Dec 19 21:25:46 2021 +0800
modify how to contribute
---
community/how-to-contribute.md | 234 ++++++++++----------
docs/deployment/quick_deploy.md | 2 +-
.../current/how-to-contribute.md | 242 +++++++++------------
.../version-1.0.2/deployment/cluster_deployment.md | 3 +-
.../version-1.0.2/deployment/web_install.md | 2 +-
.../version-1.0.2/deployment/web_install.md | 4 +-
6 files changed, 224 insertions(+), 263 deletions(-)
diff --git a/community/how-to-contribute.md b/community/how-to-contribute.md
index ea0e08d..6eaed9a 100644
--- a/community/how-to-contribute.md
+++ b/community/how-to-contribute.md
@@ -4,195 +4,181 @@ sidebar_position: 2
---
# Contributing
+| **Version Management Information Form** | |
+| ----------- | --------------------------------- |
+| Current version | Version 1.2 |
+| Current version release date | December 17, 2021 |
+| Revision information | 1. Due to the transfer of the git repository to
apache and the migration of Linkis-Doc documents to the linkis official
website, corresponding links were modified |
+
Thank you very much for contributing to the Linkis project! Before
participating in the contribution, please read the following guidelines
carefully.
## 1. Contribution category
-### 1.1 Bug feedback and fix
-
-We suggest that whether it is bug feedback or repair, you should create an
issue first to describe the status of the bug in detail, so as to help the
community to find and review issues and codes through issue records. Bug
feedback issues usually need to include a complete description
-**Bug** information and reproducible scenarios, so that the community can
quickly locate the cause of the bug and fix it. Opened issues that contain #bug
label all need to be fixed.
+### 1.1 Bug feedback and fixes
-### 1.2 Functional communication, implementation and refactoring
+We recommend that whether it is a bug feedback or a fix, an issue is first
created to describe the bug in detail, so that the community can find and
review the problem and code through the issue record. Bug feedback Issues
usually need to include **complete description of the bug information** and
**reproducible scenarios** so that the community can quickly locate the cause
of the bug and fix it. All open issues that contain the `#bug` tag need to be
fixed.
-In the communication process, please elaborate the details, mechanisms and
using scenarios of the new function(or refactoring). This can promote the
function(or refactoring) to be implemented better and faster.
-If you plan to implement a major feature (or refactoring), be sure to
communicate with the team through **Issue** or other methods, so that everyone
can move forward in the most efficient way. An open Issue containing the
#feature tag means that there are new functions need to be implemented. And
open issues including #Enhancement tags always means that needs to be improved
for refactoring.
+### 1.2 Functional communication, implementation, refactoring
+In the communication process, a detailed description, mechanisms and usage
scenarios of the new function (or refactoring) can promote it to be implemented
better and faster (including test cases and codes, and CI/CD related work).
**If you plan to implement a major feature (or refactoring), be sure to
communicate with the core development team through Issue or other means** so
that everyone can promote it in the most efficient way. Issues opened with the
label of `#feature` are all new f [...]
### 1.3 Issue Q&A
-Helping to answer the usage questions in the Issue is a very valuable way to
contribute to the Linkis community; There will always be new users keeping
coming in. While helping new users, you can also show your expertise.
+Helping answering the questions in the Linkis community is a very valuable way
to contribute; there will always be new users in the community that will keep
coming in. While helping new users, you can also show your expertise.
-### 1.4 Documentation improvements
+### 1.4 Documentation Refinements
-Linkis User Manual Documents are maintained in the Linkis-Website project of
github, you can edit the markdown file in the project and improve the document
by submit a pr.
+You can find linkis documentations at
[linkis-Website](https://linkis.apache.org/docs/latest/introduction), and the
supplement of the document is also crucial to the development of Linkis.
-## 2. Contribution process
+### 1.5 Other
+Including participating in and helping to organize community exchanges,
community operation activities, etc., and other activities that can help the
Linkis project and the community.
+
+---
+
+## 2. How to Contribution
### 2.1 Branch structure
-The Linkis source code may contain some temporary branches, but there are only
three branches as followed that are really meaningful:
+There are many branches,including temporary branches,in Linkis repository,but
only three of them matter:
-```
-master: The source code of the last stable release, and occassionally may have
several hotfix submissions
-branch-0.10.0: The latest stable version
-dev-1.0.0: Main development branch
-```
+- master: The source code of the last stable release, and occasionally hotfix
submissions;
+- release-*: stable release version;*
+- *dev-*: main development branch;
+- feature-*: Development branches for some larger new features that need to be
jointly developed by the community
+
+Please note: The dev branch of major features will be named with corresponding
naming instructions in addition to the version number, such as:
dev-0.10.0-flink, which refers to the flink feature development branch of
0.10.0.
### 2.2 Development Guidelines
-Linkis front-end and back-end code share the same code repository, but they
are separated in development. Before embarking on development, please fork a
copy of Linkis project to your own Github Repositories. When developing, please
do it based on your own Github Repositories.
+Linkis front-end and back-end code share the same code base, but they are
separated in development. Before starting the development, please fork the
Linkis project to your Github Repositories. When developing, please develop
based on the Linkis code base in your Github Repositories.
-We recommend cloning the dev-1.0.0 branch for development, so there will be
much less conflicts on merging when submitting a PR to the Linkis main project
-Much smaller
+We recommend cloning the dev-* branch for development, so that the possibility
of merge conflicts when submitting a PR to the main Linkis project will be much
smaller
-```
-git clone https://github.com/yourname/Linkis.git --branch dev-1.0.0
+```bash
+git clone https://github.com/yourname/Linkis.git --branch dev-*
```
#### 2.2.1 Backend
-The user configuration is under the project root directory /config/, the
project startup script and the upgrade patch script are under the project root
directory /bin/.
-The back-end code and core configuration are in the server/ directory, and the
log is in the project root directory /log/.
-The root directory of the project mentioned here refers to the directory
configured by the environment variable LINKIS_HOME, and the environment
variable needs to be configured during the development of the IDE.
-For example, Idea regarding the priority of environment variable loading from
high to low: Environment configured in Run/Debug Configurations
-variables —> System environment variables cached by the IDE.
+The user configuration is in the project root directory /config/, the project
startup script and the upgrade patch script are in the project root directory
/bin/, the back-end code and core configuration are in the server/ directory,
and the log is in the project root directory /log/. Note: The project root
directory referred to here refers to the directory configured by the
environment variable LINKIS_HOME, and environment variables need to be
configured during IDE development. For exam [...]
-**2.2.1.1** Directory structure
+##### 2.2.1.1 Directory structure
-```
1. Script
+
```
+├── bin # script directory
+ ├── install.sh # One-click deployment script
+ ├── start-all.sh # One-click start script
+ └── stop-all.sh # One-click stop script
```
-├── assembly-package/bin # script directory
- ├── install.sh # One-click deployment script
- ├── checkEnv.sh # Environment check script
- └── common.sh # Common script function
-```
-```
-├── sbin # script directory
- ├── linkis-daemon.sh # Single service start and stop, status detection script
- ├── linkis-start-all.sh # One-click start script
- ├── linkis-stop-all.sh # One-click stop script
- └── ext # Separate service script directory
- ├── linkis-xxx.sh # The startup script of a service
- ├── linkis-xxx.sh
- ├── ...
-```
-
-```
+
2. Configuration
+
```
+├── config # User configuration directory
+ ├── config.sh # One-click deployment configuration file
+ ├── db.sh # One-click deployment database configuration
```
-├── assembly-package/config # User configuration directory
- ├── linkis-env.sh # Configuration variable settings for one-click deployment
- ├── db.sh # One-click deployment database configuration
-```
-```
+
3. Code directory structure
-See Linkis code directory structure for details
+
+ For details, see [Linkis Code Directory
Structure](https://linkis.apache.org/docs/latest/deployment/sourcecode_hierarchical_structure)
+
4. Log directory
-```
+
```
├── logs # log root directory
```
-**2.2.1.2** Environment variables
+##### 2.2.1.2 Environment Variables
-```
-Configure system environment variable or IDE environment variable LINKIS_HOME,
it is recommended to use IDE environment variable first.
-```
-**2.2.1.3** Database
+ Configure system environment variable or IDE environment variable
LINKIS_HOME, it is recommended to use IDE environment variable first.
+
+##### 2.2.1.3 Database
-```
1. Create the Linkis system database by yourself;
-2. Modify the corresponding information of the database in conf/db.sh and
execute bin/install.sh or import directly on the database client
-db/linkis_*.sql.
-```
+2. Modify the corresponding information of the database in conf/db.sh and
execute bin/install.sh or directly import db/linkis_*.sql on the database
client.
-**2.2.1.4** Configuration file
+##### 2.2.1.4 Configuration file
-Modify the application-linkis.yml file in the conf directory and the
properties file corresponding to each microservice name to configure related
properties.
+ Modify the `application.yml` file in the resources/ directory of each
microservice to configure related properties.
-**2.2.1.5** Packaging
+##### 2.2.1.5 Packaging
-```
-1. To package the project, you need to modify the version in
/assembly/src/main/assembly/assembly.xml in the root directory, and then
execute the following command in the root directory: mvn clean package;
-To package a single module, simply run mvn clean package directly in each
module.
-```
-### 2.3 Pull Request Guidelines
+1. To obtain a complete release package, you need to modify the relevant
version information in /assembly/src/main/assembly/assembly.xml in the root
directory, and then execute: `mvn clean package` in the root directory;
+2. To obtain the package of each module, simple execute `mvn clean package` in
the module directory.
-**If you still don’t know how to initiate a PR to an open source project,
please refer to this description**
+### 2.3 Issue submission guidelines
+- If you still don’t know how to initiate a PR to an open source project,
please refer to [About
issues](https://docs.github.com/en/github/managing-your-work-on-github/about-issues)
+- Issue name, which should briefly describe your problem or suggestion in one
sentence; for the international promotion of the project, please write the
issue in English or both Chinese and English.
+- For each Issue, please bring at least two labels, component and type, such
as component=Computation Governance/EngineConn, type=Improvement. Reference:
[issue #590](https://github.com/apache/incubator-linkis/issues/590)
+
+### 2.3 Pull Request(PR) Submission Guidelines
+
+- If you still don’t know how to initiate a PR to an open source project,
please refer to [About pull
requests](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests)
+ Whether it is a bug fix or a new feature development, please submit a PR to
the dev-* branch.
+- PR and submission name follow the principle of `<type>(<scope>): <subject>`,
for details, please refer to Ruan Yifeng's [Commit message and Change log
writing
guide](http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html)
this article.
+- If the PR contains new features, the document update should be included in
this PR.
+- If this PR is not ready to merge, please add [WIP] prefix to the head of the
name (WIP = work-in-progress).
+- All submissions to dev-* branches need to go through at least one review
before they can be merged
-```
-Whether it is bug fixes or new feature development, please submit a PR to the
dev-1.0.0 branch.
-PR and submission name follow the principle of <type>(<scope>): <subject>. For
details, please refer to Ruan Yifeng's article [Commitmessage and Change log
Compilation
Guide](http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html).
-If the PR contains new features, the document update should be included in
this PR.
-If this PR is not ready to merge, please add the [WIP] prefix to the head of
the name (WIP = work-in-progress).
-All submissions to the dev-1.0.0 branch need to go through at least one review
before they can be merged
-```
### 2.4 Review Standard
-Before contributing code, you can find out what kind of submissions are
popular in Review. Simply put, if a submission can bring as many gains as
possible and as few side effects or risks as possible, then it will be reviewd
and merged first. Submissions with high risk and low value are almost
impossible to be merged, and may be rejected without even a chance to review.
+Before contributing code, you can find out what kind of submissions are
popular in Review. Simply put, if a submission can bring as many gains as
possible and as few side effects or risks as possible, the higher the
probability of it being merged, the faster the review will be. Submissions with
high risk and low value are almost impossible to merge, and may be rejected
Review.
-**2.4.1** Gain
+#### 2.4.1 Gain
-```
-Fix the main cause of the bug
-Add or fix a feature or problem that a large number of users urgently need
-Simple and effective
-Easy to test, with test cases
-Reduce complexity and amount of code
-Issues that have been discussed by the community and identified for improvement
-```
+- Fix the main cause of the bug
+- Add or fix a function or problem that a large number of users urgently need
+- Simple and effective
+- Easy to test, with test cases
+- Reduce complexity and amount of code
+- Issues that have been discussed by the community and identified for
improvement
#### 2.4.2 Side effects and risks
-```
-Only fix the surface phenomenon of the bug
-Introduce new features with high complexity
-Add complexity to meet niche needs
-Change stable existing API or semantics
-Cause other functions to not operate normally
-Add a lot of dependencies
-Change the dependency version at will
-Submit a large amount of code or changes at once
-```
-**2.4.3 Reviewer** Note
+- Only fix the surface phenomenon of the bug
+- Introduce new features with high complexity
+- Add complexity to meet niche needs
+- Change stable existing API or semantics
+- Cause other functions to not operate normally
+- Add a lot of dependencies
+- Change the dependency version at will
+- Submit a large number of codes or changes at once
-```
-Please use a constructive tone to write comments
-If you need to make changes by the submitter, please clearly state all the
content that needs to be modified to complete the Pull Request
-If a PR is found to have brought new problems after the merger, the Reviewer
needs to contact the PR author and communicate to resolve the problem.
-Question; if the PR author cannot be contacted, the Reviewer needs to restore
the PR
-```
-## 3. advanced contribution
+#### 2.4.3 Reviewer notes
+
+- Please use a constructive tone to write comments
+- If you need to make changes by the submitter, please clearly state all the
content that needs to be modified to complete the Pull Request
+- If a PR is found to have brought new problems after the merger, the Reviewer
needs to contact the PR author and communicate to solve the problem; if the PR
author cannot be contacted, the Reviewer needs to restore the PR
+
+---
+
+##3, Outstanding Contributor
### 3.1 About Committers (Collaborators)
-**3.1.1** How to become a **committer**
+#### 3.1.1 How to become Committer
-If you have had a valuable PR for the Linkis code and it has been merged, you
can contact the core development team through the official WeChat group
-Team applied to be the Committer of the Linkis project; the core development
team and other Committers will vote together to decide whether or not allow you
to join. If you get enough votes, you will become a Committer for the Linkis
project.
+If you have submitted a valuable PR to Linkis and have been merged, or
contributed continuously for more than half a year, and have led the release of
at least one version, you can find a PMC of the Linkis project through the
official WeChat group, if he is willing to nominate you as a committer , And
are willing to state your contribution to all PMC and Committer, then a vote
will be initiated; PMC and other Committers will vote together to decide
whether to allow you to join, if you ge [...]
-**3.1.2 Committer** Rights
+#### 3.1.2 Committer's
-```
-You can join the official developer WeChat group, participate in discussions
and make development plans
-Can manage Issues, including closing and adding tags
-Can create and manage project branches, except for master and dev-1.0.0
branches
-Can review the PR submitted to the dev-1.0.0 branch
-Can apply to be a member of Committee
-```
-### 3.2 About Committee
+- You can join the official developer WeChat group to participate in
discussions and formulate Linkis development plans
+- Can manage Issues, including closing and adding tags
+- Can create and manage project branches, except for master and dev-* branches
+- You can review the PR submitted to the dev-* branch
+- Can apply to become a Committee member
-**3.2.1** How to become a **Committee** member
+### 3.2 About Committee
+#### 3.2.1 How to become a Committee member
-If you are a Committer of the Linkis project, and all your contributions have
been recognized by other Committee members. Yes, you can apply to be a member
of the Linkis Committee, and other Committee members will vote together to
decide whether to allow you to join in, and if unanimously approved, you will
become a member of the Linkis Committee.
+If you are the Committer of the Linkis project, and all your contributions
have been recognized by other Committee members, you can apply to become a
member of the Linkis Committee, and other Committee members will vote together
to decide whether to allow you to join. If you pass unanimously, you will
become a member of the Linkis Committee.
-**3.2.2 Committee members' rights
+#### 3.2.2 Rights of Committee members
-```
-You can merge PRs submitted by other Committers and contributors to the
dev-1.0.0 branch
-```
\ No newline at end of file
+- You can merge PRs submitted by other Committers and contributors to the
dev-** branch
+- Participate in determining the roadmap and development direction of the
Linkis project
+- Can participate in the new version release
\ No newline at end of file
diff --git a/docs/deployment/quick_deploy.md b/docs/deployment/quick_deploy.md
index c9e6296..e8deb57 100644
--- a/docs/deployment/quick_deploy.md
+++ b/docs/deployment/quick_deploy.md
@@ -116,7 +116,7 @@ For example: **The deploy user is hadoop**.
### c. Preparing installation package
-Download the latest installation package from the Linkis release. ([Click here
to enter the download page](https://linkis.apache.org/zh-CN/download/main))
+Download the latest installation package from the Linkis release. ([Click here
to enter the download page](https://linkis.apache.org/download/main))
Decompress the installation package to the installation directory and modify
the configuration of the decompressed file.
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs-community/current/how-to-contribute.md
b/i18n/zh-CN/docusaurus-plugin-content-docs-community/current/how-to-contribute.md
index 36ab020..db6ece4 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs-community/current/how-to-contribute.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs-community/current/how-to-contribute.md
@@ -4,206 +4,180 @@ sidebar_position: 2
---
# Contributing
+| **版本管理信息表** | |
+| ----------- | --------------------------------- |
+| 现行版本 | 1.2 版 |
+| 现行版本发布日期 | 2021 年 12 月 17 日 |
+| 修订信息 | 1. 因仓库移交至apache，以及Linkis-Doc文档迁移至linkis官网，修改对应链接 |
+
非常感谢贡献Linkis项目！在参与贡献之前，请仔细阅读以下指引。
## 一、贡献范畴
### 1.1 Bug 反馈与修复
-我们建议无论是 Bug 反馈还是修复，都先创建一个 Issue 来仔细描述 Bug 的状况，以助于社
-区可以通过 Issue 记录来找到和回顾问题以及代码。Bug 反馈 Issue 通常需要包含完整描述
-**Bug** 的信息以及可复现的场景，这样社区才能快速定位导致 Bug 的原因并修复它。包含
-#bug 标签的打开的 Issue 都是需要被修复的。
+我们建议无论是 Bug 反馈还是修复，都先创建一个 Issue 来仔细描述 Bug 的状况，以助于社区可以通过 Issue
记录来找到和回顾问题以及代码。Bug 反馈 Issue 通常需要包含**完整描述 Bug 的信息**以及**可复现的场景**，这样社区才能快速定位导致 Bug
的原因并修复它。包含 `#bug` 标签的打开的 Issue 都是需要被修复的。
### 1.2 功能交流、实现、重构
-在交流过程中，详细描述新功能（或重构）的细节、机制和使用场景，能够促使它更好更快地
-被实现。如果计划实现一个重大的功能（或重构），请务必通过 **Issue** 或其他方式与核心开
-发团队进行沟通，这样大家能以最效率的方式来推进它。包含 #feature 标签的打开的 Issue
-都是需要被实现的新功能，包含 #enhancement 标签的打开的 Issue 都是需要改进重构的功
-能。
+在交流过程中，详细描述新功能（或重构）的细节、机制和使用场景，能够促使它更好更快地被实现（包括测试用例和代码，及CI/CD相关工作）。**如果计划实现一个重大的功能（或重构），请务必通过
Issue 或其他方式与核心开发团队进行沟通**，这样大家能以最效率的方式来推进它。包含 `#feature` 标签的打开的 Issue
都是需要被实现的新功能，包含 `#enhancement` 标签打开的 Issue 都是需要改进重构的功能。
### 1.3 Issue 答疑
-帮助回答 Issue 中的使用问题是为 Linkis 社区做贡献的一个非常有价值的方式；社区中总会有
-新用户不断进来，在帮助新用户的同时，也可以展现你的专业知识。
+帮助回答 Issue 中的使用问题是为 Linkis
社区做贡献的一个非常有价值的方式；社区中总会有新用户不断进来，在帮助新用户的同时，也可以展现您的专业知识。
### 1.4 文档改进
-Linkis 用户手册文档维护在github的Linkis-Website项目中，可以编辑项目里的 Markdown 文件，通过提pr的方式来对文档做改进。
+Linkis
文档位于[Linkis官网](https://linkis.apache.org/zh-CN/docs/latest/introduction/)
，文档的补充完善对于Linkis 的发展也至关重要。
+
+### 1.5 其他
+包括参与和帮助组织社区交流、社区运营活动等，其他能够帮助Linkis 项目和社区的活动。
+
+---
## 二、贡献流程
### 2.1 分支结构
-Linkis 源码可能会产生一些临时分支，但真正有明确意义的只有以下三个分支：
+Linkis 源码可能会产生一些临时分支，但真正有明确意义的只有以下三个分支：
+- master: 最近一次稳定 release 的源码，偶尔会多几次 hotfix 提交；
+- release-*: 稳定的release 版本；
+- dev-*: 主要开发分支；
+- feature-*: 针对某些较大、需要社区联合开发的新特性的开发分支
-```
-master: 最近一次稳定 release 的源码，偶尔会多几次 hotfix 提交；
-branch-0.10.0: 最新稳定版
-dev-1.0.0: 主要开发分支；
-```
+请注意：大特性的dev分支，在命名时除了版本号，还会加上相应的命名说明，如：dev-0.10.0-flink，指0.10.0的flink特性开发分支。
### 2.2 开发指引
-Linkis 前后端代码共用同一个代码库，但在开发上是分离的。在着手开发之前，请先将 Linkis
-项目 fork 一份到自己的 Github Repositories 中， 开发时请基于自己 Github Repositories 中的Linkis
代码库进行开发。
+Linkis 前后端代码共用同一个代码库，但在开发上是分离的。在着手开发之前，请先将 Linkis 项目 fork 一份到自己的 Github
Repositories 中， 开发时请基于自己 Github Repositories 中的 Linkis 代码库进行开发。
-我们建议克隆 dev-1.0.0 分支来开发，这样在向 Linkis 主项目提交 PR 时合并冲突的可能性会
-小很多
+我们建议克隆 dev-* 分支来开发，这样在向 Linkis 主项目提交 PR 时合并冲突的可能性会小很多
+```bash
+git clone https://github.com/yourname/incubator-linkis.git --branch dev-*
```
-git clone https://github.com/yourname/Linkis.git --branch dev-1.0.0
-```
+
#### 2.2.1 后端
-用户配置在项目根目录 /config/ 下，项目启动脚本和升级补丁脚本在项目根目录 /bin/ 下，
-后端代码及核心配置在 server/ 目录下, 日志在项目根目录 /log/ 下。注意：此处所指项目根目
-录都指环境变量 LINKIS_HOME 所配置的目录，在使用 IDE 开发过程中也需要配置环境变量，
-如 Idea 关于环境变量加载的优先级：Run/Debug Configurations 中配置的 Environment
-variables —> IDE缓存的系统环境变量。
+用户配置在项目根目录 /config/ 下，项目启动脚本和升级补丁脚本在项目根目录 /bin/ 下， 后端代码及核心配置在 server/ 目录下,
日志在项目根目录 /log/ 下。注意：此处所指项目根目录都指环境变量 LINKIS_HOME 所配置的目录，在使用 IDE 开发过程中也需要配置环境变量，如
Idea 关于环境变量加载的优先级：`Run/Debug Configurations` 中配置的 `Environment variables` —>
IDE缓存的系统环境变量。
-**2.2.1.1** 目录结构
+##### 2.2.1.1 目录结构
-```
1. 脚本
+
```
+├── bin # 脚本目录
+ ├── install.sh # 一键部署脚本
+ ├── start-all.sh # 一键启动脚本
+ └── stop-all.sh # 一键停止脚本
```
-├── assembly-package/bin # 脚本目录
- ├── install.sh # 一键部署脚本
- ├── checkEnv.sh # 环境检查脚本
- └── common.sh # 通用脚本函数
-```
-```
-├── sbin # 脚本目录
- ├── linkis-daemon.sh # 单服务启停、状态检测脚本
- ├── linkis-start-all.sh # 一键启动脚本
- ├── linkis-stop-all.sh # 一键停止脚本
- └── ext # 单独服务脚本目录
- ├── linkis-xxx.sh # 某个服务的启动脚本
- ├── linkis-xxx.sh
- ├── ...
-```
-
-```
+
2. 配置
+
```
+├── config # 用户配置目录
+ ├── config.sh # 一键部署的配置文件
+ ├── db.sh # 一键部署的数据库配置
```
-├── assembly-package/config # 用户配置目录
- ├── linkis-env.sh # 一键部署的配置变量设置
- ├── db.sh # 一键部署的数据库配置
-```
-```
+
3. 代码目录结构
-详见 Linkis代码目录结构
+
+ 详见
[Linkis代码目录结构](https://linkis.apache.org/zh-CN/docs/latest/deployment/sourcecode_hierarchical_structure)
+
4. 日志目录
+
```
+├── logs # 日志根目录
```
-├── logs # 日志根目录
-```
-**2.2.1.2** 环境变量
+##### 2.2.1.2 环境变量
-```
-配置系统环境变量或 IDE 环境变量 LINKIS_HOME，推荐优先使用 IDE 环境变量。
-```
-**2.2.1.3** 数据库
+ 配置系统环境变量或 IDE 环境变量 LINKIS_HOME，推荐优先使用 IDE 环境变量。
+
+##### 2.2.1.3 数据库
-```
1. 自行创建 Linkis 系统数据库；
-2. 修改 conf/db.sh 中的数据库相应信息并执行bin/install.sh 或 直接在数据库客户端导入
-db/linkis_*.sql。
-```
-**2.2.1.4** 配置文件
+2. 修改 conf/db.sh 中的数据库相应信息并执行bin/install.sh 或 直接在数据库客户端导入 db/linkis_*.sql。
-修改conf目录下的application-linkis.yml文件，以及各微服务名对应的properties文件，配置相关属性。
+##### 2.2.1.4 配置文件
-**2.2.1.5** 打包
+ 修改 每个微服务resources/ 目录下 `application.yml` 文件，配置相关属性。
-```
-1. 打完整 release 包需要修改根目录下 /assembly/src/main/assembly/assembly.xml
中相关版本信息，然后在根目录下执行: mvn clean package 即可；
-2. 打每个模块 的包可直接在 模块目录下执行 mvn clean package。
-```
-### 2.3 Pull Request 指引
+##### 2.2.1.5 打包
-** 如果你还不知道怎样向开源项目发起 PR，请参考这篇说明 **
+1. 打完整 release 包需要修改根目录下 /assembly/src/main/assembly/assembly.xml
中相关版本信息，然后在根目录下执行: `mvn clean package` 即可；
+2. 打 每个模块 的包可直接在 模块目录下执行 `mvn clean package`。
-```
-无论是 Bug 修复，还是新功能开发，请将 PR 提交到 dev-1.0.0 分支。
-PR 和提交名称遵循 <type>(<scope>): <subject> 原则，详情可以参考阮一峰的[Commitmessage 和 Change log
编写指南](http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html)
这篇文章。
-如果 PR 中包含新功能，理应将文档更新包含在本次 PR 中。
-如果本次 PR 尚未准备好合并，请在名称头部加上 [WIP] 前缀（WIP = work-in-
-progress）。
-所有提交到 dev-1.0.0 分支的提交至少需要经过一次 Review 才可以被合并
-```
-### 2.4 Review 标准
+### 2.3 Issue 提交指引
+- 如果您还不知道怎样向开源项目发起 PR，请参考[About
issues](https://docs.github.com/en/github/managing-your-work-on-github/about-issues)
+- Issue 名称，应一句话简单描述您的问题或建议；为了项目的国际化推广，请用英文，或中英文双语书写 issue.
+- 每个Issue，请至少带上component 和type 两个label，如component=Computation
Governance/EngineConn，type=Improvement.参考:[issue
#590](https://github.com/apache/incubator-linkis/issues/590)
-在贡献代码之前，可以了解一下什么样的提交在 Review 中是受欢迎的。简单来说，如果一项
-提交能带来尽可能多增益和尽可能少的副作用或风险，那它被合并的几率就越高，Review 的
-速度也会越快。风险大、价值低的提交是几乎不可能被合并的，并且有可能会被拒绝连Review 的机会都没有。
+### 2.3 Pull Request(PR) 提交指引
-**2.4.1** 增益
+- 如果您还不知道怎样向开源项目发起 PR，请参考[About pull
requests](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests)
+- 无论是 Bug 修复，还是新功能开发，请将 PR 提交到 dev-* 分支。
+- PR 和提交名称遵循 `<type>(<scope>): <subject>` 原则，详情可以参考阮一峰的 [Commit message 和
Change log
编写指南](http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html)
这篇文章。
+- 如果 PR 中包含新功能，理应将文档更新包含在本次 PR 中。
+- 如果本次 PR 尚未准备好合并，请在名称头部加上 [WIP] 前缀（WIP = work-in-progress）。
+- 所有提交到 dev-* 分支的提交至少需要经过一次 Review 才可以被合并
-```
-修复导致 Bug 的主要原因
-添加或修复一个大量用户亟需的功能或问题
-简单有效
-容易测试，有测试用例
-减少复杂度以及代码量
-经社区讨论过的、确定需要改进的问题
-```
+### 2.4 Review 标准
+
+在贡献代码之前，可以了解一下什么样的提交在 Review
中是受欢迎的。简单来说，如果一项提交能带来尽可能多增益和尽可能少的副作用或风险，那它被合并的几率就越高，Review
的速度也会越快。风险大、价值低的提交是几乎不可能被合并的，并且有可能会被拒绝 Review。
+#### 2.4.1 增益
+
+- 修复导致 Bug 的主要原因
+- 添加或修复一个大量用户亟需的功能或问题
+- 简单有效
+- 容易测试，有测试用例
+- 减少复杂度以及代码量
+- 经社区讨论过的、确定需要改进的问题
#### 2.4.2 副作用和风险
-```
-仅仅修复 Bug 的表面现象
-引入复杂度高的新功能
-为满足小众需求添加复杂度
-改动稳定的现有API或语义
-导致其他功能不能正常运行
-添加大量依赖
-随意改变依赖版本
-一次性提交大量代码或改动
-```
-**2.4.3 Reviewer** 注意事项
+- 仅仅修复 Bug 的表面现象
+- 引入复杂度高的新功能
+- 为满足小众需求添加复杂度
+- 改动稳定的现有API或语义
+- 导致其他功能不能正常运行
+- 添加大量依赖
+- 随意改变依赖版本
+- 一次性提交大量代码或改动
-```
-请使用建设性语气撰写评论
-如果需要提交者进行修改，请明确说明完成此次 Pull Request 所需要修改的所有内容
-如果某次 PR 在合并后发现带来了新问题，Reviewer 需要向 PR 作者联系并沟通解决问
-题；如果无法联系到 PR 作者，Reviewer 需要将此次 PR 进行还原
-```
-## 三、贡献进阶
+#### 2.4.3 Reviewer 注意事项
-### 3.1 关于 Committers （ Collaborators ）
+- 请使用建设性语气撰写评论
+- 如果需要提交者进行修改，请明确说明完成此次 Pull Request 所需要修改的所有内容
+- 如果某次 PR 在合并后发现带来了新问题，Reviewer 需要向 PR 作者联系并沟通解决问题；如果无法联系到 PR 作者，Reviewer
需要将此次 PR 进行还原
-**3.1.1** 如何成为 **Committer**
+---
-如果你对 Linkis 代码有过颇具价值的 PR 并且被合并，你可以通过官方微信群联系核心开发团
-队申请成为 Linkis 项目的 Committer；核心开发团队和其他 Committers 将会一起投票决定是否允许你的加入，如果得到足够票数，你将成为
Linkis 项目的 Committer。
+## 三、贡献进阶
-**3.1.2 Committer** 的权利
+### 3.1 关于 Committers（Collaborators）
-```
-可以加入官方开发者微信群，参与讨论和制定开发计划
-可以对 Issue 进行管理，包括关闭、添加标签
-可以创建和管理项目分支，master、dev-1.0.0 分支除外
-可以对提交到 dev-1.0.0 分支的 PR 进行 Review
-可以申请成为 Committee 成员
-```
-### 3.2 关于 Committee
+#### 3.1.1 如何成为 Committer
-**3.2.1** 如何成为 **Committee** 成员
+如果您对 Linkis 提过颇具价值的 PR 并且被合并，或是连续贡献超过半年，且至少主导过一次版本的发布，您可以通过官方微信群找到Linkis项目的一个
PMC ，如果他愿意提名您为 committer，并愿意为您陈述您的贡献给所有 PMC和Committer，那么接下来会发起一次投票；PMC和其他
Committers 将会一起投票决定是否允许您的加入，如果得到足够票数，您将成为 Linkis 项目的 Committer。
+#### 3.1.2 Committer 的权利
-如果你是 Linkis 项目的 Committer，并且你贡献的所有内容得到了其他 Committee 成员的认
-可，你可以申请成为 Linkis Committee 成员，其他 Committee 成员将会一起投票决定是否允
-许你的加入，如果全票通过，你将成为 Linkis Committee 成员。
+- 可以加入官方开发者微信群，参与讨论和制定Linkis开发计划
+- 可以对 Issue 进行管理，包括关闭、添加标签
+- 可以创建和管理项目分支，master、dev-* 分支除外
+- 可以对提交到 dev-* 分支的 PR 进行 Review
+- 可以申请成为 Committee 成员
-**3.2.2 Committee** 成员的权利
+### 3.2 关于 Committee
-```
-可以合并其他 Committers 和贡献者提交到 dev-1.0.0 分支的 PR
-```
+#### 3.2.1 如何成为 Committee 成员
+
+如果您是 Linkis 项目的 Committer，并且您贡献的所有内容得到了其他 Committee 成员的认可，您可以申请成为 Linkis
Committee 成员，其他 Committee 成员将会一起投票决定是否允许您的加入，如果全票通过，您将成为 Linkis Committee 成员。
+
+#### 3.2.2 Committee 成员的权利
+- 可以合并其他 Committers 和贡献者提交到 dev-** 分支的 PR
+- 可以参与决定Linkis项目的roadmap和发展方向
+- 可以参与新版本发布
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-1.0.2/deployment/cluster_deployment.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-1.0.2/deployment/cluster_deployment.md
index ebf91ca..b5265b3 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-1.0.2/deployment/cluster_deployment.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-1.0.2/deployment/cluster_deployment.md
@@ -18,7 +18,8 @@ Linkis1.0仍然保持着基于SpringCloud的微服务架构，其中每个微服
**同时在线人数 \* (所有类型的引擎占用内存) \*单用户最高并发数+ 同时在线人数 \*
(所有类型的引擎占用内存) \*单用户最高并发数**
-例如只使用spark、hive、python引擎且单用户最高并发数为1的情况下，同时使用人数50人，Spark的Driver内存1G，Hive
+例如：
+只使用spark、hive、python引擎且单用户最高并发数为1的情况下，同时使用人数50人，Spark的Driver内存1G，Hive
Client内存1G，python client 1G，每个引擎都使用1个核，那么就是 50 \*（1+1+1）G \*
1 + 50 \*(1+1+1)核\*1 = 150G 内存 + 150 CPU核数。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-1.0.2/deployment/web_install.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-1.0.2/deployment/web_install.md
index d375500..a07dcba 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-1.0.2/deployment/web_install.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-1.0.2/deployment/web_install.md
@@ -1,6 +1,6 @@
---
title: 前端管理台部署
-sidebar_position: 4
+sidebar_position: 6
---
Linkis在1.0提供了单独的前端管理台功能，提供了展示Linis的全局历史、修改用户参数、管理ECM和微服务等功能，部署前端管理台前需要先将Linkis后端进行部署，Linkis的部署手册见：[Linkis部署手册](deployment/quick_deploy.md)
diff --git a/versioned_docs/version-1.0.2/deployment/web_install.md
b/versioned_docs/version-1.0.2/deployment/web_install.md
index 150f86b..2faf3a3 100644
--- a/versioned_docs/version-1.0.2/deployment/web_install.md
+++ b/versioned_docs/version-1.0.2/deployment/web_install.md
@@ -1,9 +1,9 @@
---
title: Linkis Console Deployment
-sidebar_position: 4
+sidebar_position: 6
---
-Linkis 1.0 provides a separate front-end management console function, which
provides functions such as displaying Linis's global history, modifying user
parameters, managing ECM and microservices, etc. Before deploying the front-end
management console, you need to deploy the Linkis back-end. Linkis deployment
manual See: [Linkis Deployment Manual](deployment/quick_deploy.md)
+Linkis 1.0 provides a Linkis Console, which provides functions such as
displaying Linis's global history, modifying user parameters, managing ECM and
microservices, etc. Before deploying the front-end management console, you need
to deploy the Linkis back-end. Linkis deployment manual See: [Linkis Deployment
Manual](deployment/quick_deploy.md)
## 1. Preparation
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
