You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by GitBox <gi...@apache.org> on 2020/05/11 11:16:20 UTC
[GitHub] [flink-web] klion26 commented on a change in pull request #268: [FLINK-13343][docs-zh] Translate "Contribute Code" page into Chinese
klion26 commented on a change in pull request #268:
URL: https://github.com/apache/flink-web/pull/268#discussion_r422948951
##########
File path: contributing/contribute-code.zh.md
##########
@@ -2,17 +2,17 @@
title: "贡献代码"
---
-Apache Flink is maintained, improved, and extended by code contributions of volunteers. We welcome contributions to Flink, but due to the size of the project and to preserve the high quality of the code base, we follow a contribution process that is explained in this document.
+Apache Flink 是靠志愿者的代码贡献来得到维护、改进和扩展的项目。我们欢迎给 Flink 做贡献，但由于项目的规模大，为了保持高质量的代码库，我们要求贡献者须遵循本文中的贡献过程说明。
Review comment:
“Apache Flink 是由志愿者贡献的代码来维护、改进和扩展的。”
“但由于项目的规模，以及为了保持高质量的代码库，本文将阐述我们所遵循的流程。” -- 这个地方流程不一定好，也可以看看是否有其他更好的翻译
这个是否会更好一些呢？
##########
File path: contributing/contribute-code.zh.md
##########
@@ -2,17 +2,17 @@
title: "贡献代码"
---
-Apache Flink is maintained, improved, and extended by code contributions of volunteers. We welcome contributions to Flink, but due to the size of the project and to preserve the high quality of the code base, we follow a contribution process that is explained in this document.
+Apache Flink 是靠志愿者的代码贡献来得到维护、改进和扩展的项目。我们欢迎给 Flink 做贡献，但由于项目的规模大，为了保持高质量的代码库，我们要求贡献者须遵循本文中的贡献过程说明。
-**Please feel free to ask questions at any time.** Either send a mail to the [dev mailing list]( {{ site.base }}/community.html#mailing-lists ) or comment on the Jira issue you are working on.
+**请随时提出任何问题！** 可以发送邮件到 [dev mailing list]( {{ site.base }}/community.html#mailing-lists )，也可以对正在处理的 Jira issue 发表评论。
Review comment:
```suggestion
**请随时提出任何问题！** 可以发送邮件到 [dev mailing list]( {{ site.base }}/zh/community.html#mailing-lists )，也可以对正在处理的 Jira issue 发表评论。
```
##########
File path: contributing/contribute-code.zh.md
##########
@@ -79,44 +79,44 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="alert alert-warning" role="alert">
- <b>Note:</b> The code contribution process has changed recently (June 2019). The community <a href="https://lists.apache.org/thread.html/1e2b85d0095331606ad0411ca028f061382af08138776146589914f8@%3Cdev.flink.apache.org%3E">decided</a> to shift the "backpressure" from pull requests to Jira, by requiring contributors to get consensus (indicated by being assigned to the ticket) before opening a pull request.
+ <b>注意：</b>最近，代码贡献步骤有改动（2019 年 6 月）。社区<a href="https://lists.apache.org/thread.html/1e2b85d0095331606ad0411ca028f061382af08138776146589914f8@%3Cdev.flink.apache.org%3E">决定</a>将原来的 “backpressure”从 pull request 方式转移到 Jira，要求贡献者在打开 pull request 之前需在 Jira 上达成共识（通过分配到的工单来体现）。
Review comment:
"最近，代码贡献步骤有改动（2019 年 6 月）" 这个改成 "最近（2019 年 6 月），代码贡献步骤有改动“ 会更好一些吗？
这里 backpress 可以直接翻译成 ”压力“？
另外中英文之间需要空格，比如 `的 “backpressure”从` 需要改成 `的 “backpressure” 从`
这里的意思是，之前很多人没有在 issue 就方案达成一致，就直接提交 PR 了，导致有很多 PR，造成 Review 压力大，现在需要在提交 PR 之前在 issue 那边达成一致，这样就减少了 PR 边 review 的压力了（具体的需要再组织一下语言）
##########
File path: contributing/contribute-code.zh.md
##########
@@ -79,44 +79,44 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="alert alert-warning" role="alert">
- <b>Note:</b> The code contribution process has changed recently (June 2019). The community <a href="https://lists.apache.org/thread.html/1e2b85d0095331606ad0411ca028f061382af08138776146589914f8@%3Cdev.flink.apache.org%3E">decided</a> to shift the "backpressure" from pull requests to Jira, by requiring contributors to get consensus (indicated by being assigned to the ticket) before opening a pull request.
+ <b>注意：</b>最近，代码贡献步骤有改动（2019 年 6 月）。社区<a href="https://lists.apache.org/thread.html/1e2b85d0095331606ad0411ca028f061382af08138776146589914f8@%3Cdev.flink.apache.org%3E">决定</a>将原来的 “backpressure”从 pull request 方式转移到 Jira，要求贡献者在打开 pull request 之前需在 Jira 上达成共识（通过分配到的工单来体现）。
</div>
<div class="contribute-grid">
<div class="column">
<div class="panel panel-default">
<div class="panel-body">
- <h2><span class="number">1</span><a href="#consensus">Discuss</a></h2>
- <p>Create a Jira ticket or mailing list discussion and reach consensus</p>
- <p>Agree on importance, relevance, scope of the ticket, discuss the implementation approach and find a committer willing to review and merge the change.</p>
- <p><b>Only committers can assign a Jira ticket.</b></p>
+ <h2><span class="number">1</span><a href="#consensus">讨论</a></h2>
+ <p>在 Jira 上创建工单或邮件列表讨论并达成共识</p>
+ <p>商定重要性、相关性、工单的范围，讨论实现方案，并找到愿意审查和合并更改的 committer。</p>
+ <p><b>只有 committers 才能分配 Jira 工单。</b></p>
</div>
</div>
</div>
<div class="column">
<div class="panel panel-default">
<div class="panel-body">
- <h2><span class="number">2</span><a href="#implement">Implement</a></h2>
- <p>Implement the change according to the <a href="{{ site.base }}/contributing/code-style-and-quality.html">Code Style and Quality Guide</a> and the approach agreed upon in the Jira ticket.</p> <br />
- <p><b>Only start working on the implementation if there is consensus on the approach (e.g. you are assigned to the ticket)</b></p>
+ <h2><span class="number">2</span><a href="#implement">实现</a></h2>
+ <p>根据<a href="{{ site.base }}/contributing/code-style-and-quality.html">代码样式和质量指南</a>，以及 Jira 工单中商定的方法去实现更改。</p> <br />
Review comment:
这里的地址也需要加上 "zh" 其他地方也是一样的。（可以参考这个 [wiki](https://cwiki.apache.org/confluence/display/FLINK/Flink+Translation+Specifications)）
这些修改后，你可以在本地执行 `sh build.sh -p` 然后打开网站进行检查（超链接可以自己点击进行检查）
##########
File path: contributing/contribute-code.zh.md
##########
@@ -126,111 +126,111 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
- Note: <i>trivial</i> hot fixes such as typos or syntax errors can be opened as a <code>[hotfix]</code> pull request, without a Jira ticket.
+ 注意：诸如拼写错误或语法错误之类的<i>简单</i>热修复可以在打开 pull request 时，使用 [hotfix] 标识，可以不用 Jira ticket。
Review comment:
”可以不用 Jira ticket“ 改成”可以不创建 Jira ticket“是否会好一些呢
##########
File path: contributing/contribute-code.zh.md
##########
@@ -126,111 +126,111 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
- Note: <i>trivial</i> hot fixes such as typos or syntax errors can be opened as a <code>[hotfix]</code> pull request, without a Jira ticket.
+ 注意：诸如拼写错误或语法错误之类的<i>简单</i>热修复可以在打开 pull request 时，使用 [hotfix] 标识，可以不用 Jira ticket。
</div>
</div>
</div>
</div>
-<a name="consensus"></a>
+<a name="达成共识"></a>
-### 1. Create Jira Ticket and Reach Consensus
+### 1. 创建 Jira 工单并达成共识。
-The first step for making a contribution to Apache Flink is to reach consensus with the Flink community. This means agreeing on the scope and implementation approach of a change.
+向 Apache Flink 做出贡献的第一步是与 Flink 社区达成共识，这意味着需要一起商定更改的范围和实现的方法。
-In most cases, the discussion should happen in [Flink's bug tracker: Jira](https://issues.apache.org/jira/projects/FLINK/summary).
+在大多数情况下，讨论应该发生在 [Flink 的 Bug 跟踪器：Jira](https://issues.apache.org/jira/projects/FLINK/summary)中。
Review comment:
```suggestion
在大多数情况下，讨论应该发生在 [Flink 的 Bug 跟踪器：Jira](https://issues.apache.org/jira/projects/FLINK/summary) 中。
```
这里翻译的 `Flink 的 Bug 跟踪器` 总感觉怪怪的，这里有一个更好的翻译吗？
##########
File path: contributing/contribute-code.zh.md
##########
@@ -126,111 +126,111 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
- Note: <i>trivial</i> hot fixes such as typos or syntax errors can be opened as a <code>[hotfix]</code> pull request, without a Jira ticket.
+ 注意：诸如拼写错误或语法错误之类的<i>简单</i>热修复可以在打开 pull request 时，使用 [hotfix] 标识，可以不用 Jira ticket。
</div>
</div>
</div>
</div>
-<a name="consensus"></a>
+<a name="达成共识"></a>
-### 1. Create Jira Ticket and Reach Consensus
+### 1. 创建 Jira 工单并达成共识。
-The first step for making a contribution to Apache Flink is to reach consensus with the Flink community. This means agreeing on the scope and implementation approach of a change.
+向 Apache Flink 做出贡献的第一步是与 Flink 社区达成共识，这意味着需要一起商定更改的范围和实现的方法。
-In most cases, the discussion should happen in [Flink's bug tracker: Jira](https://issues.apache.org/jira/projects/FLINK/summary).
+在大多数情况下，讨论应该发生在 [Flink 的 Bug 跟踪器：Jira](https://issues.apache.org/jira/projects/FLINK/summary)中。
-The following types of changes require a `[DISCUSS]` thread on the dev@flink.a.o Flink mailing list:
+以下类型的更改需要在 dev@flink.apache.org Flink 邮件列表中标识 `[DISCUSS]`:
- - big changes (major new feature; big refactorings, involving multiple components)
- - potentially controversial changes or issues
- - changes with very unclear approaches or multiple equal approaches
+ - 重大变化（主要新功能、大重构和涉及多个组件）
+ - 可能存在争议的变化或问题
+ - 采用非常不明确的方法或多种相同方法的变化
Review comment:
这里是说某个方案可能有种实现方法的时候需要讨论吧，这样可以让大家达成一致
##########
File path: contributing/contribute-code.zh.md
##########
@@ -126,111 +126,111 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
- Note: <i>trivial</i> hot fixes such as typos or syntax errors can be opened as a <code>[hotfix]</code> pull request, without a Jira ticket.
+ 注意：诸如拼写错误或语法错误之类的<i>简单</i>热修复可以在打开 pull request 时，使用 [hotfix] 标识，可以不用 Jira ticket。
</div>
</div>
</div>
</div>
-<a name="consensus"></a>
+<a name="达成共识"></a>
-### 1. Create Jira Ticket and Reach Consensus
+### 1. 创建 Jira 工单并达成共识。
-The first step for making a contribution to Apache Flink is to reach consensus with the Flink community. This means agreeing on the scope and implementation approach of a change.
+向 Apache Flink 做出贡献的第一步是与 Flink 社区达成共识，这意味着需要一起商定更改的范围和实现的方法。
-In most cases, the discussion should happen in [Flink's bug tracker: Jira](https://issues.apache.org/jira/projects/FLINK/summary).
+在大多数情况下，讨论应该发生在 [Flink 的 Bug 跟踪器：Jira](https://issues.apache.org/jira/projects/FLINK/summary)中。
-The following types of changes require a `[DISCUSS]` thread on the dev@flink.a.o Flink mailing list:
+以下类型的更改需要在 dev@flink.apache.org Flink 邮件列表中标识 `[DISCUSS]`:
Review comment:
这里是说下面这些修改，需要往 dev 邮件列表发一封以 `[DISCUSS]` 开头的邮件，可以参考[这封邮件](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Releasing-quot-fat-quot-and-quot-slim-quot-Flink-distributions-td40237.html)
##########
File path: contributing/contribute-code.zh.md
##########
@@ -126,111 +126,111 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
- Note: <i>trivial</i> hot fixes such as typos or syntax errors can be opened as a <code>[hotfix]</code> pull request, without a Jira ticket.
+ 注意：诸如拼写错误或语法错误之类的<i>简单</i>热修复可以在打开 pull request 时，使用 [hotfix] 标识，可以不用 Jira ticket。
</div>
</div>
</div>
</div>
-<a name="consensus"></a>
+<a name="达成共识"></a>
-### 1. Create Jira Ticket and Reach Consensus
+### 1. 创建 Jira 工单并达成共识。
-The first step for making a contribution to Apache Flink is to reach consensus with the Flink community. This means agreeing on the scope and implementation approach of a change.
+向 Apache Flink 做出贡献的第一步是与 Flink 社区达成共识，这意味着需要一起商定更改的范围和实现的方法。
-In most cases, the discussion should happen in [Flink's bug tracker: Jira](https://issues.apache.org/jira/projects/FLINK/summary).
+在大多数情况下，讨论应该发生在 [Flink 的 Bug 跟踪器：Jira](https://issues.apache.org/jira/projects/FLINK/summary)中。
-The following types of changes require a `[DISCUSS]` thread on the dev@flink.a.o Flink mailing list:
+以下类型的更改需要在 dev@flink.apache.org Flink 邮件列表中标识 `[DISCUSS]`:
- - big changes (major new feature; big refactorings, involving multiple components)
- - potentially controversial changes or issues
- - changes with very unclear approaches or multiple equal approaches
+ - 重大变化（主要新功能、大重构和涉及多个组件）
+ - 可能存在争议的变化或问题
+ - 采用非常不明确的方法或多种相同方法的变化
- Do not open a Jira ticket for these types of changes before the discussion has come to a conclusion.
- Jira tickets based on a dev@ discussion need to link to that discussion and should summarize the outcome.
+ 在讨论结束之前,不要为这些类型的更改打开 Jira 工单。
Review comment:
这里是说，在讨论达成一致前，不要在 Jira 创建工单。
PS：全文中 ticket 需要保持一致（建议都翻译成工单），或者你觉得更合适的词语
##########
File path: contributing/contribute-code.zh.md
##########
@@ -126,111 +126,111 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
- Note: <i>trivial</i> hot fixes such as typos or syntax errors can be opened as a <code>[hotfix]</code> pull request, without a Jira ticket.
+ 注意：诸如拼写错误或语法错误之类的<i>简单</i>热修复可以在打开 pull request 时，使用 [hotfix] 标识，可以不用 Jira ticket。
</div>
</div>
</div>
</div>
-<a name="consensus"></a>
+<a name="达成共识"></a>
-### 1. Create Jira Ticket and Reach Consensus
+### 1. 创建 Jira 工单并达成共识。
-The first step for making a contribution to Apache Flink is to reach consensus with the Flink community. This means agreeing on the scope and implementation approach of a change.
+向 Apache Flink 做出贡献的第一步是与 Flink 社区达成共识，这意味着需要一起商定更改的范围和实现的方法。
-In most cases, the discussion should happen in [Flink's bug tracker: Jira](https://issues.apache.org/jira/projects/FLINK/summary).
+在大多数情况下，讨论应该发生在 [Flink 的 Bug 跟踪器：Jira](https://issues.apache.org/jira/projects/FLINK/summary)中。
-The following types of changes require a `[DISCUSS]` thread on the dev@flink.a.o Flink mailing list:
+以下类型的更改需要在 dev@flink.apache.org Flink 邮件列表中标识 `[DISCUSS]`:
- - big changes (major new feature; big refactorings, involving multiple components)
- - potentially controversial changes or issues
- - changes with very unclear approaches or multiple equal approaches
+ - 重大变化（主要新功能、大重构和涉及多个组件）
+ - 可能存在争议的变化或问题
+ - 采用非常不明确的方法或多种相同方法的变化
- Do not open a Jira ticket for these types of changes before the discussion has come to a conclusion.
- Jira tickets based on a dev@ discussion need to link to that discussion and should summarize the outcome.
+ 在讨论结束之前,不要为这些类型的更改打开 Jira 工单。
+ 基于 dev 邮件讨论的 Jira 工单需要链接到该讨论，并总结结果。
-**Requirements for a Jira ticket to get consensus:**
+**Jira 工单获得共识的要求：**
- - Formal requirements
- - The *Title* describes the problem concisely.
- - The *Description* gives all the details needed to understand the problem or feature request.
- - The *Component* field is set: Many committers and contributors only focus on certain subsystems of Flink. Setting the appropriate component is important for getting their attention.
- - There is **agreement** that the ticket solves a valid problem, and that it is a **good fit** for Flink.
- The Flink community considers the following aspects:
- - Does the contribution alter the behavior of features or components in a way that it may break previous users’ programs and setups? If yes, there needs to be a discussion and agreement that this change is desirable.
- - Does the contribution conceptually fit well into Flink? Is it too much of a special case such that it makes things more complicated for the common case, or bloats the abstractions / APIs?
- - Does the feature fit well into Flink’s architecture? Will it scale and keep Flink flexible for the future, or will the feature restrict Flink in the future?
- - Is the feature a significant new addition (rather than an improvement to an existing part)? If yes, will the Flink community commit to maintaining this feature?
- - Does this feature align well with Flink's roadmap and currently ongoing efforts?
- - Does the feature produce added value for Flink users or developers? Or does it introduce the risk of regression without adding relevant user or developer benefit?
- - Could the contribution live in another repository, e.g., Apache Bahir or another external repository?
- - Is this a contribution just for the sake of getting a commit in an open source project (fixing typos, style changes merely for taste reasons)
- - There is **consensus** on how to solve the problem. This includes considerations such as
- - API and data backwards compatibility and migration strategies
- - Testing strategies
- - Impact on Flink's build time
- - Dependencies and their licenses
+ - 正式要求
+ - 描述问题的 *Title* 要简明扼要。
+ - 在 *Description* 中要提供了解问题或功能请求所需的所有详细信息。
+ - 要设置 *Component* 字段：许多 committers 和贡献者，只专注于 Flink 的某些子系统。设置适当的组件标签对于引起他们的注意很重要。
+ - 社区*一致同意*使用 tickets 是有效解决问题的方法，而且这**非常适合** Flink。
+ Flink 社区考虑了以下几个方面：
+ - 这种贡献是否会改变特性或组件的性能，从而破坏以前的用户程序和设置？如果是，那么就需要讨论并达成一致意见，证明这种改变是可取的。
+ - 这个贡献在概念上是否适合 Flink ？这是一个特殊情况，是因为它使简单问题变复杂，还是使 abstractions 或者 APIs 变得臃肿？
+ - 该功能是否适合 Flink 的架构？它是否易扩展并保持 Flink 未来的灵活性，或者该功能将来会限制 Flink 吗？
+ - 该特性是一个重要的新增(而不是对现有部分的改进)吗？如果是，Flink 社区会承诺维护这个特性吗？
Review comment:
”该特性是一个重要的新增(而不是对现有部分的改进)吗“ 这句话感觉不太通顺
这句话，新增是一个名词，个人觉得不太符合我们的日常用语习惯
##########
File path: contributing/contribute-code.zh.md
##########
@@ -126,111 +126,111 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
- Note: <i>trivial</i> hot fixes such as typos or syntax errors can be opened as a <code>[hotfix]</code> pull request, without a Jira ticket.
+ 注意：诸如拼写错误或语法错误之类的<i>简单</i>热修复可以在打开 pull request 时，使用 [hotfix] 标识，可以不用 Jira ticket。
</div>
</div>
</div>
</div>
-<a name="consensus"></a>
+<a name="达成共识"></a>
-### 1. Create Jira Ticket and Reach Consensus
+### 1. 创建 Jira 工单并达成共识。
-The first step for making a contribution to Apache Flink is to reach consensus with the Flink community. This means agreeing on the scope and implementation approach of a change.
+向 Apache Flink 做出贡献的第一步是与 Flink 社区达成共识，这意味着需要一起商定更改的范围和实现的方法。
-In most cases, the discussion should happen in [Flink's bug tracker: Jira](https://issues.apache.org/jira/projects/FLINK/summary).
+在大多数情况下，讨论应该发生在 [Flink 的 Bug 跟踪器：Jira](https://issues.apache.org/jira/projects/FLINK/summary)中。
-The following types of changes require a `[DISCUSS]` thread on the dev@flink.a.o Flink mailing list:
+以下类型的更改需要在 dev@flink.apache.org Flink 邮件列表中标识 `[DISCUSS]`:
- - big changes (major new feature; big refactorings, involving multiple components)
- - potentially controversial changes or issues
- - changes with very unclear approaches or multiple equal approaches
+ - 重大变化（主要新功能、大重构和涉及多个组件）
+ - 可能存在争议的变化或问题
+ - 采用非常不明确的方法或多种相同方法的变化
- Do not open a Jira ticket for these types of changes before the discussion has come to a conclusion.
- Jira tickets based on a dev@ discussion need to link to that discussion and should summarize the outcome.
+ 在讨论结束之前,不要为这些类型的更改打开 Jira 工单。
+ 基于 dev 邮件讨论的 Jira 工单需要链接到该讨论，并总结结果。
-**Requirements for a Jira ticket to get consensus:**
+**Jira 工单获得共识的要求：**
- - Formal requirements
- - The *Title* describes the problem concisely.
- - The *Description* gives all the details needed to understand the problem or feature request.
- - The *Component* field is set: Many committers and contributors only focus on certain subsystems of Flink. Setting the appropriate component is important for getting their attention.
- - There is **agreement** that the ticket solves a valid problem, and that it is a **good fit** for Flink.
- The Flink community considers the following aspects:
- - Does the contribution alter the behavior of features or components in a way that it may break previous users’ programs and setups? If yes, there needs to be a discussion and agreement that this change is desirable.
- - Does the contribution conceptually fit well into Flink? Is it too much of a special case such that it makes things more complicated for the common case, or bloats the abstractions / APIs?
- - Does the feature fit well into Flink’s architecture? Will it scale and keep Flink flexible for the future, or will the feature restrict Flink in the future?
- - Is the feature a significant new addition (rather than an improvement to an existing part)? If yes, will the Flink community commit to maintaining this feature?
- - Does this feature align well with Flink's roadmap and currently ongoing efforts?
- - Does the feature produce added value for Flink users or developers? Or does it introduce the risk of regression without adding relevant user or developer benefit?
- - Could the contribution live in another repository, e.g., Apache Bahir or another external repository?
- - Is this a contribution just for the sake of getting a commit in an open source project (fixing typos, style changes merely for taste reasons)
- - There is **consensus** on how to solve the problem. This includes considerations such as
- - API and data backwards compatibility and migration strategies
- - Testing strategies
- - Impact on Flink's build time
- - Dependencies and their licenses
+ - 正式要求
+ - 描述问题的 *Title* 要简明扼要。
+ - 在 *Description* 中要提供了解问题或功能请求所需的所有详细信息。
+ - 要设置 *Component* 字段：许多 committers 和贡献者，只专注于 Flink 的某些子系统。设置适当的组件标签对于引起他们的注意很重要。
+ - 社区*一致同意*使用 tickets 是有效解决问题的方法，而且这**非常适合** Flink。
+ Flink 社区考虑了以下几个方面：
+ - 这种贡献是否会改变特性或组件的性能，从而破坏以前的用户程序和设置？如果是，那么就需要讨论并达成一致意见，证明这种改变是可取的。
+ - 这个贡献在概念上是否适合 Flink ？这是一个特殊情况，是因为它使简单问题变复杂，还是使 abstractions 或者 APIs 变得臃肿？
Review comment:
这里后面一句话是说，讨论的内容是否是一种 ”special case“？支持这种 ”special case“之后会导致通用的 case 更复杂，整理抽象或者 API 更臃肿 等
##########
File path: contributing/contribute-code.zh.md
##########
@@ -126,111 +126,111 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
- Note: <i>trivial</i> hot fixes such as typos or syntax errors can be opened as a <code>[hotfix]</code> pull request, without a Jira ticket.
+ 注意：诸如拼写错误或语法错误之类的<i>简单</i>热修复可以在打开 pull request 时，使用 [hotfix] 标识，可以不用 Jira ticket。
</div>
</div>
</div>
</div>
-<a name="consensus"></a>
+<a name="达成共识"></a>
-### 1. Create Jira Ticket and Reach Consensus
+### 1. 创建 Jira 工单并达成共识。
-The first step for making a contribution to Apache Flink is to reach consensus with the Flink community. This means agreeing on the scope and implementation approach of a change.
+向 Apache Flink 做出贡献的第一步是与 Flink 社区达成共识，这意味着需要一起商定更改的范围和实现的方法。
-In most cases, the discussion should happen in [Flink's bug tracker: Jira](https://issues.apache.org/jira/projects/FLINK/summary).
+在大多数情况下，讨论应该发生在 [Flink 的 Bug 跟踪器：Jira](https://issues.apache.org/jira/projects/FLINK/summary)中。
-The following types of changes require a `[DISCUSS]` thread on the dev@flink.a.o Flink mailing list:
+以下类型的更改需要在 dev@flink.apache.org Flink 邮件列表中标识 `[DISCUSS]`:
- - big changes (major new feature; big refactorings, involving multiple components)
- - potentially controversial changes or issues
- - changes with very unclear approaches or multiple equal approaches
+ - 重大变化（主要新功能、大重构和涉及多个组件）
+ - 可能存在争议的变化或问题
+ - 采用非常不明确的方法或多种相同方法的变化
- Do not open a Jira ticket for these types of changes before the discussion has come to a conclusion.
- Jira tickets based on a dev@ discussion need to link to that discussion and should summarize the outcome.
+ 在讨论结束之前,不要为这些类型的更改打开 Jira 工单。
+ 基于 dev 邮件讨论的 Jira 工单需要链接到该讨论，并总结结果。
-**Requirements for a Jira ticket to get consensus:**
+**Jira 工单获得共识的要求：**
- - Formal requirements
- - The *Title* describes the problem concisely.
- - The *Description* gives all the details needed to understand the problem or feature request.
- - The *Component* field is set: Many committers and contributors only focus on certain subsystems of Flink. Setting the appropriate component is important for getting their attention.
- - There is **agreement** that the ticket solves a valid problem, and that it is a **good fit** for Flink.
- The Flink community considers the following aspects:
- - Does the contribution alter the behavior of features or components in a way that it may break previous users’ programs and setups? If yes, there needs to be a discussion and agreement that this change is desirable.
- - Does the contribution conceptually fit well into Flink? Is it too much of a special case such that it makes things more complicated for the common case, or bloats the abstractions / APIs?
- - Does the feature fit well into Flink’s architecture? Will it scale and keep Flink flexible for the future, or will the feature restrict Flink in the future?
- - Is the feature a significant new addition (rather than an improvement to an existing part)? If yes, will the Flink community commit to maintaining this feature?
- - Does this feature align well with Flink's roadmap and currently ongoing efforts?
- - Does the feature produce added value for Flink users or developers? Or does it introduce the risk of regression without adding relevant user or developer benefit?
- - Could the contribution live in another repository, e.g., Apache Bahir or another external repository?
- - Is this a contribution just for the sake of getting a commit in an open source project (fixing typos, style changes merely for taste reasons)
- - There is **consensus** on how to solve the problem. This includes considerations such as
- - API and data backwards compatibility and migration strategies
- - Testing strategies
- - Impact on Flink's build time
- - Dependencies and their licenses
+ - 正式要求
+ - 描述问题的 *Title* 要简明扼要。
+ - 在 *Description* 中要提供了解问题或功能请求所需的所有详细信息。
+ - 要设置 *Component* 字段：许多 committers 和贡献者，只专注于 Flink 的某些子系统。设置适当的组件标签对于引起他们的注意很重要。
+ - 社区*一致同意*使用 tickets 是有效解决问题的方法，而且这**非常适合** Flink。
+ Flink 社区考虑了以下几个方面：
+ - 这种贡献是否会改变特性或组件的性能，从而破坏以前的用户程序和设置？如果是，那么就需要讨论并达成一致意见，证明这种改变是可取的。
+ - 这个贡献在概念上是否适合 Flink ？这是一个特殊情况，是因为它使简单问题变复杂，还是使 abstractions 或者 APIs 变得臃肿？
+ - 该功能是否适合 Flink 的架构？它是否易扩展并保持 Flink 未来的灵活性，或者该功能将来会限制 Flink 吗？
+ - 该特性是一个重要的新增(而不是对现有部分的改进)吗？如果是，Flink 社区会承诺维护这个特性吗？
+ - 这个特性是否与 Flink 的路线图以及当前正在进行的工作内容一致？
+ - 该特性是否为 Flink 用户或开发人员带来了附加价值？或者它引入了回归的风险而没有给相关的用户或开发人员带来好处？
+ - 该贡献是否存在于另一个存储库中，例如 Apache Bahir 或另一个外部存储库？
+ - 这仅仅是为了在开源项目中获得提交而做出的贡献吗（仅仅是为了获得贡献而贡献，才去修复拼写错误、改变代码风格）?
+ - 在如何解决这个问题上已有**共识**，包括以下需要考虑的因素
+ - API 、数据向后兼容性和迁移策略
+ - 测试策略
+ - 对 Flink 构建时间的影响
+ - 依赖关系及其许可证
-If a change is identified as a large or controversial change in the discussion on Jira, it might require a [Flink Improvement Proposal (FLIP)](https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals) or a discussion on the [dev mailing list]( {{ site.base }}/community.html#mailing-lists) to reach agreement and consensus.
+如果在 Jira 的讨论中发现改动是一个大的或有争议的变更，则可能需要有 [Flink 改动建议 ( FLIP )](https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals) 或在 [ dev 邮件列表]( {{ site.base }}/community.html#mailing-lists) 中讨论以达成一致意见。
-Contributors can expect to get a first reaction from a committer within a few days after opening the ticket. If a ticket doesn't get any attention, we recommend reaching out to the [developer mailing list]( {{ site.base }}/community.html#mailing-lists). Note that the Flink community sometimes does not have the capacity to accept all incoming contributions.
+贡献者可以在打开 ticket 后的几天内得到来自 committer 的第一回应。如果 ticket 没有得到任何关注，我们建议你联系 [dev 邮件列表]( {{ site.base }}/community.html#mailing-lists)。请注意，Flink 社区有时没有能力接受发来的所有贡献信息。
-Once all requirements for the ticket are met, a committer will assign somebody to the *`Assignee`* field of the ticket to work on it.
-Only committers have the permission to assign somebody.
+一旦满足了 ticket 的所有要求，committer 就会将某人*`分配`*给 ticket 的受理人以进行处理。
Review comment:
这里是说把 ticket 分配给具体的人，这样就可以开始写代码或者其他的贡献了。
##########
File path: contributing/contribute-code.zh.md
##########
@@ -126,111 +126,111 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
- Note: <i>trivial</i> hot fixes such as typos or syntax errors can be opened as a <code>[hotfix]</code> pull request, without a Jira ticket.
+ 注意：诸如拼写错误或语法错误之类的<i>简单</i>热修复可以在打开 pull request 时，使用 [hotfix] 标识，可以不用 Jira ticket。
</div>
</div>
</div>
</div>
-<a name="consensus"></a>
+<a name="达成共识"></a>
-### 1. Create Jira Ticket and Reach Consensus
+### 1. 创建 Jira 工单并达成共识。
-The first step for making a contribution to Apache Flink is to reach consensus with the Flink community. This means agreeing on the scope and implementation approach of a change.
+向 Apache Flink 做出贡献的第一步是与 Flink 社区达成共识，这意味着需要一起商定更改的范围和实现的方法。
-In most cases, the discussion should happen in [Flink's bug tracker: Jira](https://issues.apache.org/jira/projects/FLINK/summary).
+在大多数情况下，讨论应该发生在 [Flink 的 Bug 跟踪器：Jira](https://issues.apache.org/jira/projects/FLINK/summary)中。
-The following types of changes require a `[DISCUSS]` thread on the dev@flink.a.o Flink mailing list:
+以下类型的更改需要在 dev@flink.apache.org Flink 邮件列表中标识 `[DISCUSS]`:
- - big changes (major new feature; big refactorings, involving multiple components)
- - potentially controversial changes or issues
- - changes with very unclear approaches or multiple equal approaches
+ - 重大变化（主要新功能、大重构和涉及多个组件）
+ - 可能存在争议的变化或问题
+ - 采用非常不明确的方法或多种相同方法的变化
- Do not open a Jira ticket for these types of changes before the discussion has come to a conclusion.
- Jira tickets based on a dev@ discussion need to link to that discussion and should summarize the outcome.
+ 在讨论结束之前,不要为这些类型的更改打开 Jira 工单。
+ 基于 dev 邮件讨论的 Jira 工单需要链接到该讨论，并总结结果。
-**Requirements for a Jira ticket to get consensus:**
+**Jira 工单获得共识的要求：**
- - Formal requirements
- - The *Title* describes the problem concisely.
- - The *Description* gives all the details needed to understand the problem or feature request.
- - The *Component* field is set: Many committers and contributors only focus on certain subsystems of Flink. Setting the appropriate component is important for getting their attention.
- - There is **agreement** that the ticket solves a valid problem, and that it is a **good fit** for Flink.
- The Flink community considers the following aspects:
- - Does the contribution alter the behavior of features or components in a way that it may break previous users’ programs and setups? If yes, there needs to be a discussion and agreement that this change is desirable.
- - Does the contribution conceptually fit well into Flink? Is it too much of a special case such that it makes things more complicated for the common case, or bloats the abstractions / APIs?
- - Does the feature fit well into Flink’s architecture? Will it scale and keep Flink flexible for the future, or will the feature restrict Flink in the future?
- - Is the feature a significant new addition (rather than an improvement to an existing part)? If yes, will the Flink community commit to maintaining this feature?
- - Does this feature align well with Flink's roadmap and currently ongoing efforts?
- - Does the feature produce added value for Flink users or developers? Or does it introduce the risk of regression without adding relevant user or developer benefit?
- - Could the contribution live in another repository, e.g., Apache Bahir or another external repository?
- - Is this a contribution just for the sake of getting a commit in an open source project (fixing typos, style changes merely for taste reasons)
- - There is **consensus** on how to solve the problem. This includes considerations such as
- - API and data backwards compatibility and migration strategies
- - Testing strategies
- - Impact on Flink's build time
- - Dependencies and their licenses
+ - 正式要求
+ - 描述问题的 *Title* 要简明扼要。
+ - 在 *Description* 中要提供了解问题或功能请求所需的所有详细信息。
+ - 要设置 *Component* 字段：许多 committers 和贡献者，只专注于 Flink 的某些子系统。设置适当的组件标签对于引起他们的注意很重要。
+ - 社区*一致同意*使用 tickets 是有效解决问题的方法，而且这**非常适合** Flink。
+ Flink 社区考虑了以下几个方面：
+ - 这种贡献是否会改变特性或组件的性能，从而破坏以前的用户程序和设置？如果是，那么就需要讨论并达成一致意见，证明这种改变是可取的。
+ - 这个贡献在概念上是否适合 Flink ？这是一个特殊情况，是因为它使简单问题变复杂，还是使 abstractions 或者 APIs 变得臃肿？
+ - 该功能是否适合 Flink 的架构？它是否易扩展并保持 Flink 未来的灵活性，或者该功能将来会限制 Flink 吗？
+ - 该特性是一个重要的新增(而不是对现有部分的改进)吗？如果是，Flink 社区会承诺维护这个特性吗？
+ - 这个特性是否与 Flink 的路线图以及当前正在进行的工作内容一致？
+ - 该特性是否为 Flink 用户或开发人员带来了附加价值？或者它引入了回归的风险而没有给相关的用户或开发人员带来好处？
+ - 该贡献是否存在于另一个存储库中，例如 Apache Bahir 或另一个外部存储库？
+ - 这仅仅是为了在开源项目中获得提交而做出的贡献吗（仅仅是为了获得贡献而贡献，才去修复拼写错误、改变代码风格）?
+ - 在如何解决这个问题上已有**共识**，包括以下需要考虑的因素
+ - API 、数据向后兼容性和迁移策略
Review comment:
```suggestion
- API、数据向后兼容性和迁移策略
```
##########
File path: contributing/contribute-code.zh.md
##########
@@ -126,111 +126,111 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
- Note: <i>trivial</i> hot fixes such as typos or syntax errors can be opened as a <code>[hotfix]</code> pull request, without a Jira ticket.
+ 注意：诸如拼写错误或语法错误之类的<i>简单</i>热修复可以在打开 pull request 时，使用 [hotfix] 标识，可以不用 Jira ticket。
</div>
</div>
</div>
</div>
-<a name="consensus"></a>
+<a name="达成共识"></a>
-### 1. Create Jira Ticket and Reach Consensus
+### 1. 创建 Jira 工单并达成共识。
-The first step for making a contribution to Apache Flink is to reach consensus with the Flink community. This means agreeing on the scope and implementation approach of a change.
+向 Apache Flink 做出贡献的第一步是与 Flink 社区达成共识，这意味着需要一起商定更改的范围和实现的方法。
-In most cases, the discussion should happen in [Flink's bug tracker: Jira](https://issues.apache.org/jira/projects/FLINK/summary).
+在大多数情况下，讨论应该发生在 [Flink 的 Bug 跟踪器：Jira](https://issues.apache.org/jira/projects/FLINK/summary)中。
-The following types of changes require a `[DISCUSS]` thread on the dev@flink.a.o Flink mailing list:
+以下类型的更改需要在 dev@flink.apache.org Flink 邮件列表中标识 `[DISCUSS]`:
- - big changes (major new feature; big refactorings, involving multiple components)
- - potentially controversial changes or issues
- - changes with very unclear approaches or multiple equal approaches
+ - 重大变化（主要新功能、大重构和涉及多个组件）
+ - 可能存在争议的变化或问题
+ - 采用非常不明确的方法或多种相同方法的变化
- Do not open a Jira ticket for these types of changes before the discussion has come to a conclusion.
- Jira tickets based on a dev@ discussion need to link to that discussion and should summarize the outcome.
+ 在讨论结束之前,不要为这些类型的更改打开 Jira 工单。
+ 基于 dev 邮件讨论的 Jira 工单需要链接到该讨论，并总结结果。
-**Requirements for a Jira ticket to get consensus:**
+**Jira 工单获得共识的要求：**
- - Formal requirements
- - The *Title* describes the problem concisely.
- - The *Description* gives all the details needed to understand the problem or feature request.
- - The *Component* field is set: Many committers and contributors only focus on certain subsystems of Flink. Setting the appropriate component is important for getting their attention.
- - There is **agreement** that the ticket solves a valid problem, and that it is a **good fit** for Flink.
- The Flink community considers the following aspects:
- - Does the contribution alter the behavior of features or components in a way that it may break previous users’ programs and setups? If yes, there needs to be a discussion and agreement that this change is desirable.
- - Does the contribution conceptually fit well into Flink? Is it too much of a special case such that it makes things more complicated for the common case, or bloats the abstractions / APIs?
- - Does the feature fit well into Flink’s architecture? Will it scale and keep Flink flexible for the future, or will the feature restrict Flink in the future?
- - Is the feature a significant new addition (rather than an improvement to an existing part)? If yes, will the Flink community commit to maintaining this feature?
- - Does this feature align well with Flink's roadmap and currently ongoing efforts?
- - Does the feature produce added value for Flink users or developers? Or does it introduce the risk of regression without adding relevant user or developer benefit?
- - Could the contribution live in another repository, e.g., Apache Bahir or another external repository?
- - Is this a contribution just for the sake of getting a commit in an open source project (fixing typos, style changes merely for taste reasons)
- - There is **consensus** on how to solve the problem. This includes considerations such as
- - API and data backwards compatibility and migration strategies
- - Testing strategies
- - Impact on Flink's build time
- - Dependencies and their licenses
+ - 正式要求
+ - 描述问题的 *Title* 要简明扼要。
+ - 在 *Description* 中要提供了解问题或功能请求所需的所有详细信息。
+ - 要设置 *Component* 字段：许多 committers 和贡献者，只专注于 Flink 的某些子系统。设置适当的组件标签对于引起他们的注意很重要。
+ - 社区*一致同意*使用 tickets 是有效解决问题的方法，而且这**非常适合** Flink。
+ Flink 社区考虑了以下几个方面：
+ - 这种贡献是否会改变特性或组件的性能，从而破坏以前的用户程序和设置？如果是，那么就需要讨论并达成一致意见，证明这种改变是可取的。
+ - 这个贡献在概念上是否适合 Flink ？这是一个特殊情况，是因为它使简单问题变复杂，还是使 abstractions 或者 APIs 变得臃肿？
+ - 该功能是否适合 Flink 的架构？它是否易扩展并保持 Flink 未来的灵活性，或者该功能将来会限制 Flink 吗？
+ - 该特性是一个重要的新增(而不是对现有部分的改进)吗？如果是，Flink 社区会承诺维护这个特性吗？
+ - 这个特性是否与 Flink 的路线图以及当前正在进行的工作内容一致？
+ - 该特性是否为 Flink 用户或开发人员带来了附加价值？或者它引入了回归的风险而没有给相关的用户或开发人员带来好处？
+ - 该贡献是否存在于另一个存储库中，例如 Apache Bahir 或另一个外部存储库？
Review comment:
这里的 ”存储库“ 是否有更好的翻译呢？这里的意思是指第三方的库，也就是 Flink 之外提供类似功能的系统或者 Jar 等
##########
File path: contributing/contribute-code.zh.md
##########
@@ -126,111 +126,111 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
- Note: <i>trivial</i> hot fixes such as typos or syntax errors can be opened as a <code>[hotfix]</code> pull request, without a Jira ticket.
+ 注意：诸如拼写错误或语法错误之类的<i>简单</i>热修复可以在打开 pull request 时，使用 [hotfix] 标识，可以不用 Jira ticket。
</div>
</div>
</div>
</div>
-<a name="consensus"></a>
+<a name="达成共识"></a>
-### 1. Create Jira Ticket and Reach Consensus
+### 1. 创建 Jira 工单并达成共识。
-The first step for making a contribution to Apache Flink is to reach consensus with the Flink community. This means agreeing on the scope and implementation approach of a change.
+向 Apache Flink 做出贡献的第一步是与 Flink 社区达成共识，这意味着需要一起商定更改的范围和实现的方法。
-In most cases, the discussion should happen in [Flink's bug tracker: Jira](https://issues.apache.org/jira/projects/FLINK/summary).
+在大多数情况下，讨论应该发生在 [Flink 的 Bug 跟踪器：Jira](https://issues.apache.org/jira/projects/FLINK/summary)中。
-The following types of changes require a `[DISCUSS]` thread on the dev@flink.a.o Flink mailing list:
+以下类型的更改需要在 dev@flink.apache.org Flink 邮件列表中标识 `[DISCUSS]`:
- - big changes (major new feature; big refactorings, involving multiple components)
- - potentially controversial changes or issues
- - changes with very unclear approaches or multiple equal approaches
+ - 重大变化（主要新功能、大重构和涉及多个组件）
+ - 可能存在争议的变化或问题
+ - 采用非常不明确的方法或多种相同方法的变化
- Do not open a Jira ticket for these types of changes before the discussion has come to a conclusion.
- Jira tickets based on a dev@ discussion need to link to that discussion and should summarize the outcome.
+ 在讨论结束之前,不要为这些类型的更改打开 Jira 工单。
+ 基于 dev 邮件讨论的 Jira 工单需要链接到该讨论，并总结结果。
-**Requirements for a Jira ticket to get consensus:**
+**Jira 工单获得共识的要求：**
- - Formal requirements
- - The *Title* describes the problem concisely.
- - The *Description* gives all the details needed to understand the problem or feature request.
- - The *Component* field is set: Many committers and contributors only focus on certain subsystems of Flink. Setting the appropriate component is important for getting their attention.
- - There is **agreement** that the ticket solves a valid problem, and that it is a **good fit** for Flink.
- The Flink community considers the following aspects:
- - Does the contribution alter the behavior of features or components in a way that it may break previous users’ programs and setups? If yes, there needs to be a discussion and agreement that this change is desirable.
- - Does the contribution conceptually fit well into Flink? Is it too much of a special case such that it makes things more complicated for the common case, or bloats the abstractions / APIs?
- - Does the feature fit well into Flink’s architecture? Will it scale and keep Flink flexible for the future, or will the feature restrict Flink in the future?
- - Is the feature a significant new addition (rather than an improvement to an existing part)? If yes, will the Flink community commit to maintaining this feature?
- - Does this feature align well with Flink's roadmap and currently ongoing efforts?
- - Does the feature produce added value for Flink users or developers? Or does it introduce the risk of regression without adding relevant user or developer benefit?
- - Could the contribution live in another repository, e.g., Apache Bahir or another external repository?
- - Is this a contribution just for the sake of getting a commit in an open source project (fixing typos, style changes merely for taste reasons)
- - There is **consensus** on how to solve the problem. This includes considerations such as
- - API and data backwards compatibility and migration strategies
- - Testing strategies
- - Impact on Flink's build time
- - Dependencies and their licenses
+ - 正式要求
+ - 描述问题的 *Title* 要简明扼要。
+ - 在 *Description* 中要提供了解问题或功能请求所需的所有详细信息。
+ - 要设置 *Component* 字段：许多 committers 和贡献者，只专注于 Flink 的某些子系统。设置适当的组件标签对于引起他们的注意很重要。
+ - 社区*一致同意*使用 tickets 是有效解决问题的方法，而且这**非常适合** Flink。
+ Flink 社区考虑了以下几个方面：
+ - 这种贡献是否会改变特性或组件的性能，从而破坏以前的用户程序和设置？如果是，那么就需要讨论并达成一致意见，证明这种改变是可取的。
+ - 这个贡献在概念上是否适合 Flink ？这是一个特殊情况，是因为它使简单问题变复杂，还是使 abstractions 或者 APIs 变得臃肿？
+ - 该功能是否适合 Flink 的架构？它是否易扩展并保持 Flink 未来的灵活性，或者该功能将来会限制 Flink 吗？
+ - 该特性是一个重要的新增(而不是对现有部分的改进)吗？如果是，Flink 社区会承诺维护这个特性吗？
+ - 这个特性是否与 Flink 的路线图以及当前正在进行的工作内容一致？
+ - 该特性是否为 Flink 用户或开发人员带来了附加价值？或者它引入了回归的风险而没有给相关的用户或开发人员带来好处？
+ - 该贡献是否存在于另一个存储库中，例如 Apache Bahir 或另一个外部存储库？
+ - 这仅仅是为了在开源项目中获得提交而做出的贡献吗（仅仅是为了获得贡献而贡献，才去修复拼写错误、改变代码风格）?
+ - 在如何解决这个问题上已有**共识**，包括以下需要考虑的因素
+ - API 、数据向后兼容性和迁移策略
+ - 测试策略
+ - 对 Flink 构建时间的影响
+ - 依赖关系及其许可证
-If a change is identified as a large or controversial change in the discussion on Jira, it might require a [Flink Improvement Proposal (FLIP)](https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals) or a discussion on the [dev mailing list]( {{ site.base }}/community.html#mailing-lists) to reach agreement and consensus.
+如果在 Jira 的讨论中发现改动是一个大的或有争议的变更，则可能需要有 [Flink 改动建议 ( FLIP )](https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals) 或在 [ dev 邮件列表]( {{ site.base }}/community.html#mailing-lists) 中讨论以达成一致意见。
-Contributors can expect to get a first reaction from a committer within a few days after opening the ticket. If a ticket doesn't get any attention, we recommend reaching out to the [developer mailing list]( {{ site.base }}/community.html#mailing-lists). Note that the Flink community sometimes does not have the capacity to accept all incoming contributions.
+贡献者可以在打开 ticket 后的几天内得到来自 committer 的第一回应。如果 ticket 没有得到任何关注，我们建议你联系 [dev 邮件列表]( {{ site.base }}/community.html#mailing-lists)。请注意，Flink 社区有时没有能力接受发来的所有贡献信息。
-Once all requirements for the ticket are met, a committer will assign somebody to the *`Assignee`* field of the ticket to work on it.
-Only committers have the permission to assign somebody.
+一旦满足了 ticket 的所有要求，committer 就会将某人*`分配`*给 ticket 的受理人以进行处理。
+只有 committer 才有权限分配 ticket 给某人。
-**Pull requests belonging to unassigned Jira tickets will not be reviewed or merged by the community**.
+**社区不会审查或合并属于未分配的 Jira ticket 的 pull request ！**
-<a name="implement"></a>
+<a name="实现"></a>
Review comment:
这里建议不翻译，另外几个也同理
这个是用来在页面内跳转用的，比如 100 行的 `#implement ` 会跳转到这里
##########
File path: contributing/contribute-code.zh.md
##########
@@ -126,111 +126,111 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
- Note: <i>trivial</i> hot fixes such as typos or syntax errors can be opened as a <code>[hotfix]</code> pull request, without a Jira ticket.
+ 注意：诸如拼写错误或语法错误之类的<i>简单</i>热修复可以在打开 pull request 时，使用 [hotfix] 标识，可以不用 Jira ticket。
</div>
</div>
</div>
</div>
-<a name="consensus"></a>
+<a name="达成共识"></a>
-### 1. Create Jira Ticket and Reach Consensus
+### 1. 创建 Jira 工单并达成共识。
-The first step for making a contribution to Apache Flink is to reach consensus with the Flink community. This means agreeing on the scope and implementation approach of a change.
+向 Apache Flink 做出贡献的第一步是与 Flink 社区达成共识，这意味着需要一起商定更改的范围和实现的方法。
-In most cases, the discussion should happen in [Flink's bug tracker: Jira](https://issues.apache.org/jira/projects/FLINK/summary).
+在大多数情况下，讨论应该发生在 [Flink 的 Bug 跟踪器：Jira](https://issues.apache.org/jira/projects/FLINK/summary)中。
-The following types of changes require a `[DISCUSS]` thread on the dev@flink.a.o Flink mailing list:
+以下类型的更改需要在 dev@flink.apache.org Flink 邮件列表中标识 `[DISCUSS]`:
- - big changes (major new feature; big refactorings, involving multiple components)
- - potentially controversial changes or issues
- - changes with very unclear approaches or multiple equal approaches
+ - 重大变化（主要新功能、大重构和涉及多个组件）
+ - 可能存在争议的变化或问题
+ - 采用非常不明确的方法或多种相同方法的变化
- Do not open a Jira ticket for these types of changes before the discussion has come to a conclusion.
- Jira tickets based on a dev@ discussion need to link to that discussion and should summarize the outcome.
+ 在讨论结束之前,不要为这些类型的更改打开 Jira 工单。
+ 基于 dev 邮件讨论的 Jira 工单需要链接到该讨论，并总结结果。
-**Requirements for a Jira ticket to get consensus:**
+**Jira 工单获得共识的要求：**
- - Formal requirements
- - The *Title* describes the problem concisely.
- - The *Description* gives all the details needed to understand the problem or feature request.
- - The *Component* field is set: Many committers and contributors only focus on certain subsystems of Flink. Setting the appropriate component is important for getting their attention.
- - There is **agreement** that the ticket solves a valid problem, and that it is a **good fit** for Flink.
- The Flink community considers the following aspects:
- - Does the contribution alter the behavior of features or components in a way that it may break previous users’ programs and setups? If yes, there needs to be a discussion and agreement that this change is desirable.
- - Does the contribution conceptually fit well into Flink? Is it too much of a special case such that it makes things more complicated for the common case, or bloats the abstractions / APIs?
- - Does the feature fit well into Flink’s architecture? Will it scale and keep Flink flexible for the future, or will the feature restrict Flink in the future?
- - Is the feature a significant new addition (rather than an improvement to an existing part)? If yes, will the Flink community commit to maintaining this feature?
- - Does this feature align well with Flink's roadmap and currently ongoing efforts?
- - Does the feature produce added value for Flink users or developers? Or does it introduce the risk of regression without adding relevant user or developer benefit?
- - Could the contribution live in another repository, e.g., Apache Bahir or another external repository?
- - Is this a contribution just for the sake of getting a commit in an open source project (fixing typos, style changes merely for taste reasons)
- - There is **consensus** on how to solve the problem. This includes considerations such as
- - API and data backwards compatibility and migration strategies
- - Testing strategies
- - Impact on Flink's build time
- - Dependencies and their licenses
+ - 正式要求
+ - 描述问题的 *Title* 要简明扼要。
+ - 在 *Description* 中要提供了解问题或功能请求所需的所有详细信息。
+ - 要设置 *Component* 字段：许多 committers 和贡献者，只专注于 Flink 的某些子系统。设置适当的组件标签对于引起他们的注意很重要。
+ - 社区*一致同意*使用 tickets 是有效解决问题的方法，而且这**非常适合** Flink。
+ Flink 社区考虑了以下几个方面：
+ - 这种贡献是否会改变特性或组件的性能，从而破坏以前的用户程序和设置？如果是，那么就需要讨论并达成一致意见，证明这种改变是可取的。
+ - 这个贡献在概念上是否适合 Flink ？这是一个特殊情况，是因为它使简单问题变复杂，还是使 abstractions 或者 APIs 变得臃肿？
+ - 该功能是否适合 Flink 的架构？它是否易扩展并保持 Flink 未来的灵活性，或者该功能将来会限制 Flink 吗？
+ - 该特性是一个重要的新增(而不是对现有部分的改进)吗？如果是，Flink 社区会承诺维护这个特性吗？
+ - 这个特性是否与 Flink 的路线图以及当前正在进行的工作内容一致？
+ - 该特性是否为 Flink 用户或开发人员带来了附加价值？或者它引入了回归的风险而没有给相关的用户或开发人员带来好处？
+ - 该贡献是否存在于另一个存储库中，例如 Apache Bahir 或另一个外部存储库？
+ - 这仅仅是为了在开源项目中获得提交而做出的贡献吗（仅仅是为了获得贡献而贡献，才去修复拼写错误、改变代码风格）?
+ - 在如何解决这个问题上已有**共识**，包括以下需要考虑的因素
+ - API 、数据向后兼容性和迁移策略
+ - 测试策略
+ - 对 Flink 构建时间的影响
+ - 依赖关系及其许可证
-If a change is identified as a large or controversial change in the discussion on Jira, it might require a [Flink Improvement Proposal (FLIP)](https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals) or a discussion on the [dev mailing list]( {{ site.base }}/community.html#mailing-lists) to reach agreement and consensus.
+如果在 Jira 的讨论中发现改动是一个大的或有争议的变更，则可能需要有 [Flink 改动建议 ( FLIP )](https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals) 或在 [ dev 邮件列表]( {{ site.base }}/community.html#mailing-lists) 中讨论以达成一致意见。
-Contributors can expect to get a first reaction from a committer within a few days after opening the ticket. If a ticket doesn't get any attention, we recommend reaching out to the [developer mailing list]( {{ site.base }}/community.html#mailing-lists). Note that the Flink community sometimes does not have the capacity to accept all incoming contributions.
+贡献者可以在打开 ticket 后的几天内得到来自 committer 的第一回应。如果 ticket 没有得到任何关注，我们建议你联系 [dev 邮件列表]( {{ site.base }}/community.html#mailing-lists)。请注意，Flink 社区有时没有能力接受发来的所有贡献信息。
-Once all requirements for the ticket are met, a committer will assign somebody to the *`Assignee`* field of the ticket to work on it.
-Only committers have the permission to assign somebody.
+一旦满足了 ticket 的所有要求，committer 就会将某人*`分配`*给 ticket 的受理人以进行处理。
+只有 committer 才有权限分配 ticket 给某人。
Review comment:
这句话不太通顺，这里是指只有 commiter 才能分配 ticket（包括分配给他自己和其他人）
##########
File path: contributing/contribute-code.zh.md
##########
@@ -126,111 +126,111 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
- Note: <i>trivial</i> hot fixes such as typos or syntax errors can be opened as a <code>[hotfix]</code> pull request, without a Jira ticket.
+ 注意：诸如拼写错误或语法错误之类的<i>简单</i>热修复可以在打开 pull request 时，使用 [hotfix] 标识，可以不用 Jira ticket。
</div>
</div>
</div>
</div>
-<a name="consensus"></a>
+<a name="达成共识"></a>
-### 1. Create Jira Ticket and Reach Consensus
+### 1. 创建 Jira 工单并达成共识。
-The first step for making a contribution to Apache Flink is to reach consensus with the Flink community. This means agreeing on the scope and implementation approach of a change.
+向 Apache Flink 做出贡献的第一步是与 Flink 社区达成共识，这意味着需要一起商定更改的范围和实现的方法。
-In most cases, the discussion should happen in [Flink's bug tracker: Jira](https://issues.apache.org/jira/projects/FLINK/summary).
+在大多数情况下，讨论应该发生在 [Flink 的 Bug 跟踪器：Jira](https://issues.apache.org/jira/projects/FLINK/summary)中。
-The following types of changes require a `[DISCUSS]` thread on the dev@flink.a.o Flink mailing list:
+以下类型的更改需要在 dev@flink.apache.org Flink 邮件列表中标识 `[DISCUSS]`:
- - big changes (major new feature; big refactorings, involving multiple components)
- - potentially controversial changes or issues
- - changes with very unclear approaches or multiple equal approaches
+ - 重大变化（主要新功能、大重构和涉及多个组件）
+ - 可能存在争议的变化或问题
+ - 采用非常不明确的方法或多种相同方法的变化
- Do not open a Jira ticket for these types of changes before the discussion has come to a conclusion.
- Jira tickets based on a dev@ discussion need to link to that discussion and should summarize the outcome.
+ 在讨论结束之前,不要为这些类型的更改打开 Jira 工单。
+ 基于 dev 邮件讨论的 Jira 工单需要链接到该讨论，并总结结果。
-**Requirements for a Jira ticket to get consensus:**
+**Jira 工单获得共识的要求：**
- - Formal requirements
- - The *Title* describes the problem concisely.
- - The *Description* gives all the details needed to understand the problem or feature request.
- - The *Component* field is set: Many committers and contributors only focus on certain subsystems of Flink. Setting the appropriate component is important for getting their attention.
- - There is **agreement** that the ticket solves a valid problem, and that it is a **good fit** for Flink.
- The Flink community considers the following aspects:
- - Does the contribution alter the behavior of features or components in a way that it may break previous users’ programs and setups? If yes, there needs to be a discussion and agreement that this change is desirable.
- - Does the contribution conceptually fit well into Flink? Is it too much of a special case such that it makes things more complicated for the common case, or bloats the abstractions / APIs?
- - Does the feature fit well into Flink’s architecture? Will it scale and keep Flink flexible for the future, or will the feature restrict Flink in the future?
- - Is the feature a significant new addition (rather than an improvement to an existing part)? If yes, will the Flink community commit to maintaining this feature?
- - Does this feature align well with Flink's roadmap and currently ongoing efforts?
- - Does the feature produce added value for Flink users or developers? Or does it introduce the risk of regression without adding relevant user or developer benefit?
- - Could the contribution live in another repository, e.g., Apache Bahir or another external repository?
- - Is this a contribution just for the sake of getting a commit in an open source project (fixing typos, style changes merely for taste reasons)
- - There is **consensus** on how to solve the problem. This includes considerations such as
- - API and data backwards compatibility and migration strategies
- - Testing strategies
- - Impact on Flink's build time
- - Dependencies and their licenses
+ - 正式要求
+ - 描述问题的 *Title* 要简明扼要。
+ - 在 *Description* 中要提供了解问题或功能请求所需的所有详细信息。
+ - 要设置 *Component* 字段：许多 committers 和贡献者，只专注于 Flink 的某些子系统。设置适当的组件标签对于引起他们的注意很重要。
+ - 社区*一致同意*使用 tickets 是有效解决问题的方法，而且这**非常适合** Flink。
+ Flink 社区考虑了以下几个方面：
+ - 这种贡献是否会改变特性或组件的性能，从而破坏以前的用户程序和设置？如果是，那么就需要讨论并达成一致意见，证明这种改变是可取的。
+ - 这个贡献在概念上是否适合 Flink ？这是一个特殊情况，是因为它使简单问题变复杂，还是使 abstractions 或者 APIs 变得臃肿？
+ - 该功能是否适合 Flink 的架构？它是否易扩展并保持 Flink 未来的灵活性，或者该功能将来会限制 Flink 吗？
+ - 该特性是一个重要的新增(而不是对现有部分的改进)吗？如果是，Flink 社区会承诺维护这个特性吗？
+ - 这个特性是否与 Flink 的路线图以及当前正在进行的工作内容一致？
+ - 该特性是否为 Flink 用户或开发人员带来了附加价值？或者它引入了回归的风险而没有给相关的用户或开发人员带来好处？
+ - 该贡献是否存在于另一个存储库中，例如 Apache Bahir 或另一个外部存储库？
+ - 这仅仅是为了在开源项目中获得提交而做出的贡献吗（仅仅是为了获得贡献而贡献，才去修复拼写错误、改变代码风格）?
+ - 在如何解决这个问题上已有**共识**，包括以下需要考虑的因素
+ - API 、数据向后兼容性和迁移策略
+ - 测试策略
+ - 对 Flink 构建时间的影响
+ - 依赖关系及其许可证
-If a change is identified as a large or controversial change in the discussion on Jira, it might require a [Flink Improvement Proposal (FLIP)](https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals) or a discussion on the [dev mailing list]( {{ site.base }}/community.html#mailing-lists) to reach agreement and consensus.
+如果在 Jira 的讨论中发现改动是一个大的或有争议的变更，则可能需要有 [Flink 改动建议 ( FLIP )](https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals) 或在 [ dev 邮件列表]( {{ site.base }}/community.html#mailing-lists) 中讨论以达成一致意见。
-Contributors can expect to get a first reaction from a committer within a few days after opening the ticket. If a ticket doesn't get any attention, we recommend reaching out to the [developer mailing list]( {{ site.base }}/community.html#mailing-lists). Note that the Flink community sometimes does not have the capacity to accept all incoming contributions.
+贡献者可以在打开 ticket 后的几天内得到来自 committer 的第一回应。如果 ticket 没有得到任何关注，我们建议你联系 [dev 邮件列表]( {{ site.base }}/community.html#mailing-lists)。请注意，Flink 社区有时没有能力接受发来的所有贡献信息。
-Once all requirements for the ticket are met, a committer will assign somebody to the *`Assignee`* field of the ticket to work on it.
-Only committers have the permission to assign somebody.
+一旦满足了 ticket 的所有要求，committer 就会将某人*`分配`*给 ticket 的受理人以进行处理。
+只有 committer 才有权限分配 ticket 给某人。
-**Pull requests belonging to unassigned Jira tickets will not be reviewed or merged by the community**.
+**社区不会审查或合并属于未分配的 Jira ticket 的 pull request ！**
-<a name="implement"></a>
+<a name="实现"></a>
-### 2. Implement your change
+### 2. 实现你想改动的
-Once you've been assigned to a Jira issue, you may start to implement the required changes.
+一旦你被分配到了 Jira issue，你就可以开始去实现你想改动的内容。
-Here are some further points to keep in mind while implementing:
+以下是在实现时要注意的一些要点：
-- [Set up a Flink development environment](https://cwiki.apache.org/confluence/display/FLINK/Setting+up+a+Flink+development+environment)
-- Follow the [Code Style and Quality Guide]({{ site.base }}/contributing/code-style-and-quality.html) of Flink
-- Take any discussions and requirements from the Jira issue or design document into account.
-- Do not mix unrelated issues into one contribution.
+- [设置 Flink 的开发环境](https://cwiki.apache.org/confluence/display/FLINK/Setting+up+a+Flink+development+environment)
+- 遵循 Flink 的 [代码风格和质量指南]({{ site.base }}/contributing/code-style-and-quality.html)
+- 接受来自 Jira issue 或设计文档中的任何讨论和要求。
+- 不要将不相关的问题混合到一个贡献中。
-<a name="review"></a>
+<a name="审查"></a>
-### 3. Open a Pull Request
+### 3. 打开一个 Pull Request
-Considerations before opening a pull request:
+在打开 pull request 之前的注意事项：
- - Make sure that **`mvn clean verify`** is passing on your changes to ensure that all checks pass, the code builds and that all tests pass.
- - Execute the [End to End tests of Flink](https://github.com/apache/flink/tree/master/flink-end-to-end-tests#running-tests).
- - Make sure no unrelated or unnecessary reformatting changes are included.
- - Make sure your commit history adheres to the requirements.
- - Make sure your change has been rebased to the latest commits in your base branch.
- - Make sure the pull request refers to the respective Jira, and that each Jira issue is assigned to exactly one pull request (in case of multiple pull requests for one Jira; resolve that situation first)
+ - 确保 **`mvn clean verify`** 验证了你的更改，以确保所有检查都通过，代码构建并且所有测试都通过。
+ - 执行 [Flink 的端到端测试](https://github.com/apache/flink/tree/master/flink-end-to-end-tests#running-tests)。
+ - 确保不包含任何不相关或不必要的格式化更改。
+ - 确保你的提交历史符合要求。
+ - 确保更改是重新基于你的基本分支中的最新提交。
+ - 确保 pull request 引用的是相应的 Jira，并且每个 Jira issue 都分配给了一个 pull request（如果一个 Jira 有多个 pull requests，首先解决这种情况）
- Considerations before or right after opening a pull request:
+ 打开 pull request 之前或之后的注意事项：
- - Make sure that the branch is building successfully on [Travis](https://travis-ci.org/).
+ - 确保分支在 [Travis](https://travis-ci.org/) 上已经成功构建。
Review comment:
```suggestion
- 确保分支在 [Travis](https://travis-ci.org/) 上已经成功构建。
```
##########
File path: contributing/contribute-code.zh.md
##########
@@ -126,111 +126,111 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
- Note: <i>trivial</i> hot fixes such as typos or syntax errors can be opened as a <code>[hotfix]</code> pull request, without a Jira ticket.
+ 注意：诸如拼写错误或语法错误之类的<i>简单</i>热修复可以在打开 pull request 时，使用 [hotfix] 标识，可以不用 Jira ticket。
</div>
</div>
</div>
</div>
-<a name="consensus"></a>
+<a name="达成共识"></a>
-### 1. Create Jira Ticket and Reach Consensus
+### 1. 创建 Jira 工单并达成共识。
-The first step for making a contribution to Apache Flink is to reach consensus with the Flink community. This means agreeing on the scope and implementation approach of a change.
+向 Apache Flink 做出贡献的第一步是与 Flink 社区达成共识，这意味着需要一起商定更改的范围和实现的方法。
-In most cases, the discussion should happen in [Flink's bug tracker: Jira](https://issues.apache.org/jira/projects/FLINK/summary).
+在大多数情况下，讨论应该发生在 [Flink 的 Bug 跟踪器：Jira](https://issues.apache.org/jira/projects/FLINK/summary)中。
-The following types of changes require a `[DISCUSS]` thread on the dev@flink.a.o Flink mailing list:
+以下类型的更改需要在 dev@flink.apache.org Flink 邮件列表中标识 `[DISCUSS]`:
- - big changes (major new feature; big refactorings, involving multiple components)
- - potentially controversial changes or issues
- - changes with very unclear approaches or multiple equal approaches
+ - 重大变化（主要新功能、大重构和涉及多个组件）
+ - 可能存在争议的变化或问题
+ - 采用非常不明确的方法或多种相同方法的变化
- Do not open a Jira ticket for these types of changes before the discussion has come to a conclusion.
- Jira tickets based on a dev@ discussion need to link to that discussion and should summarize the outcome.
+ 在讨论结束之前,不要为这些类型的更改打开 Jira 工单。
+ 基于 dev 邮件讨论的 Jira 工单需要链接到该讨论，并总结结果。
-**Requirements for a Jira ticket to get consensus:**
+**Jira 工单获得共识的要求：**
- - Formal requirements
- - The *Title* describes the problem concisely.
- - The *Description* gives all the details needed to understand the problem or feature request.
- - The *Component* field is set: Many committers and contributors only focus on certain subsystems of Flink. Setting the appropriate component is important for getting their attention.
- - There is **agreement** that the ticket solves a valid problem, and that it is a **good fit** for Flink.
- The Flink community considers the following aspects:
- - Does the contribution alter the behavior of features or components in a way that it may break previous users’ programs and setups? If yes, there needs to be a discussion and agreement that this change is desirable.
- - Does the contribution conceptually fit well into Flink? Is it too much of a special case such that it makes things more complicated for the common case, or bloats the abstractions / APIs?
- - Does the feature fit well into Flink’s architecture? Will it scale and keep Flink flexible for the future, or will the feature restrict Flink in the future?
- - Is the feature a significant new addition (rather than an improvement to an existing part)? If yes, will the Flink community commit to maintaining this feature?
- - Does this feature align well with Flink's roadmap and currently ongoing efforts?
- - Does the feature produce added value for Flink users or developers? Or does it introduce the risk of regression without adding relevant user or developer benefit?
- - Could the contribution live in another repository, e.g., Apache Bahir or another external repository?
- - Is this a contribution just for the sake of getting a commit in an open source project (fixing typos, style changes merely for taste reasons)
- - There is **consensus** on how to solve the problem. This includes considerations such as
- - API and data backwards compatibility and migration strategies
- - Testing strategies
- - Impact on Flink's build time
- - Dependencies and their licenses
+ - 正式要求
+ - 描述问题的 *Title* 要简明扼要。
+ - 在 *Description* 中要提供了解问题或功能请求所需的所有详细信息。
+ - 要设置 *Component* 字段：许多 committers 和贡献者，只专注于 Flink 的某些子系统。设置适当的组件标签对于引起他们的注意很重要。
+ - 社区*一致同意*使用 tickets 是有效解决问题的方法，而且这**非常适合** Flink。
+ Flink 社区考虑了以下几个方面：
+ - 这种贡献是否会改变特性或组件的性能，从而破坏以前的用户程序和设置？如果是，那么就需要讨论并达成一致意见，证明这种改变是可取的。
+ - 这个贡献在概念上是否适合 Flink ？这是一个特殊情况，是因为它使简单问题变复杂，还是使 abstractions 或者 APIs 变得臃肿？
+ - 该功能是否适合 Flink 的架构？它是否易扩展并保持 Flink 未来的灵活性，或者该功能将来会限制 Flink 吗？
+ - 该特性是一个重要的新增(而不是对现有部分的改进)吗？如果是，Flink 社区会承诺维护这个特性吗？
+ - 这个特性是否与 Flink 的路线图以及当前正在进行的工作内容一致？
+ - 该特性是否为 Flink 用户或开发人员带来了附加价值？或者它引入了回归的风险而没有给相关的用户或开发人员带来好处？
+ - 该贡献是否存在于另一个存储库中，例如 Apache Bahir 或另一个外部存储库？
+ - 这仅仅是为了在开源项目中获得提交而做出的贡献吗（仅仅是为了获得贡献而贡献，才去修复拼写错误、改变代码风格）?
+ - 在如何解决这个问题上已有**共识**，包括以下需要考虑的因素
+ - API 、数据向后兼容性和迁移策略
+ - 测试策略
+ - 对 Flink 构建时间的影响
+ - 依赖关系及其许可证
-If a change is identified as a large or controversial change in the discussion on Jira, it might require a [Flink Improvement Proposal (FLIP)](https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals) or a discussion on the [dev mailing list]( {{ site.base }}/community.html#mailing-lists) to reach agreement and consensus.
+如果在 Jira 的讨论中发现改动是一个大的或有争议的变更，则可能需要有 [Flink 改动建议 ( FLIP )](https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals) 或在 [ dev 邮件列表]( {{ site.base }}/community.html#mailing-lists) 中讨论以达成一致意见。
-Contributors can expect to get a first reaction from a committer within a few days after opening the ticket. If a ticket doesn't get any attention, we recommend reaching out to the [developer mailing list]( {{ site.base }}/community.html#mailing-lists). Note that the Flink community sometimes does not have the capacity to accept all incoming contributions.
+贡献者可以在打开 ticket 后的几天内得到来自 committer 的第一回应。如果 ticket 没有得到任何关注，我们建议你联系 [dev 邮件列表]( {{ site.base }}/community.html#mailing-lists)。请注意，Flink 社区有时没有能力接受发来的所有贡献信息。
-Once all requirements for the ticket are met, a committer will assign somebody to the *`Assignee`* field of the ticket to work on it.
-Only committers have the permission to assign somebody.
+一旦满足了 ticket 的所有要求，committer 就会将某人*`分配`*给 ticket 的受理人以进行处理。
+只有 committer 才有权限分配 ticket 给某人。
-**Pull requests belonging to unassigned Jira tickets will not be reviewed or merged by the community**.
+**社区不会审查或合并属于未分配的 Jira ticket 的 pull request ！**
-<a name="implement"></a>
+<a name="实现"></a>
-### 2. Implement your change
+### 2. 实现你想改动的
-Once you've been assigned to a Jira issue, you may start to implement the required changes.
+一旦你被分配到了 Jira issue，你就可以开始去实现你想改动的内容。
-Here are some further points to keep in mind while implementing:
+以下是在实现时要注意的一些要点：
-- [Set up a Flink development environment](https://cwiki.apache.org/confluence/display/FLINK/Setting+up+a+Flink+development+environment)
-- Follow the [Code Style and Quality Guide]({{ site.base }}/contributing/code-style-and-quality.html) of Flink
-- Take any discussions and requirements from the Jira issue or design document into account.
-- Do not mix unrelated issues into one contribution.
+- [设置 Flink 的开发环境](https://cwiki.apache.org/confluence/display/FLINK/Setting+up+a+Flink+development+environment)
+- 遵循 Flink 的 [代码风格和质量指南]({{ site.base }}/contributing/code-style-and-quality.html)
+- 接受来自 Jira issue 或设计文档中的任何讨论和要求。
+- 不要将不相关的问题混合到一个贡献中。
-<a name="review"></a>
+<a name="审查"></a>
-### 3. Open a Pull Request
+### 3. 打开一个 Pull Request
-Considerations before opening a pull request:
+在打开 pull request 之前的注意事项：
- - Make sure that **`mvn clean verify`** is passing on your changes to ensure that all checks pass, the code builds and that all tests pass.
- - Execute the [End to End tests of Flink](https://github.com/apache/flink/tree/master/flink-end-to-end-tests#running-tests).
- - Make sure no unrelated or unnecessary reformatting changes are included.
- - Make sure your commit history adheres to the requirements.
- - Make sure your change has been rebased to the latest commits in your base branch.
- - Make sure the pull request refers to the respective Jira, and that each Jira issue is assigned to exactly one pull request (in case of multiple pull requests for one Jira; resolve that situation first)
+ - 确保 **`mvn clean verify`** 验证了你的更改，以确保所有检查都通过，代码构建并且所有测试都通过。
+ - 执行 [Flink 的端到端测试](https://github.com/apache/flink/tree/master/flink-end-to-end-tests#running-tests)。
+ - 确保不包含任何不相关或不必要的格式化更改。
+ - 确保你的提交历史符合要求。
+ - 确保更改是重新基于你的基本分支中的最新提交。
Review comment:
这里有比 基本分支 更好的翻译吗？这里 ”base branch“ 是指你基于这个分支提叫 PR
##########
File path: contributing/contribute-code.zh.md
##########
@@ -126,111 +126,111 @@ Apache Flink is maintained, improved, and extended by code contributions of volu
<div class="col-sm-12">
<div class="panel panel-default">
<div class="panel-body">
- Note: <i>trivial</i> hot fixes such as typos or syntax errors can be opened as a <code>[hotfix]</code> pull request, without a Jira ticket.
+ 注意：诸如拼写错误或语法错误之类的<i>简单</i>热修复可以在打开 pull request 时，使用 [hotfix] 标识，可以不用 Jira ticket。
</div>
</div>
</div>
</div>
-<a name="consensus"></a>
+<a name="达成共识"></a>
-### 1. Create Jira Ticket and Reach Consensus
+### 1. 创建 Jira 工单并达成共识。
-The first step for making a contribution to Apache Flink is to reach consensus with the Flink community. This means agreeing on the scope and implementation approach of a change.
+向 Apache Flink 做出贡献的第一步是与 Flink 社区达成共识，这意味着需要一起商定更改的范围和实现的方法。
-In most cases, the discussion should happen in [Flink's bug tracker: Jira](https://issues.apache.org/jira/projects/FLINK/summary).
+在大多数情况下，讨论应该发生在 [Flink 的 Bug 跟踪器：Jira](https://issues.apache.org/jira/projects/FLINK/summary)中。
-The following types of changes require a `[DISCUSS]` thread on the dev@flink.a.o Flink mailing list:
+以下类型的更改需要在 dev@flink.apache.org Flink 邮件列表中标识 `[DISCUSS]`:
- - big changes (major new feature; big refactorings, involving multiple components)
- - potentially controversial changes or issues
- - changes with very unclear approaches or multiple equal approaches
+ - 重大变化（主要新功能、大重构和涉及多个组件）
+ - 可能存在争议的变化或问题
+ - 采用非常不明确的方法或多种相同方法的变化
- Do not open a Jira ticket for these types of changes before the discussion has come to a conclusion.
- Jira tickets based on a dev@ discussion need to link to that discussion and should summarize the outcome.
+ 在讨论结束之前,不要为这些类型的更改打开 Jira 工单。
+ 基于 dev 邮件讨论的 Jira 工单需要链接到该讨论，并总结结果。
-**Requirements for a Jira ticket to get consensus:**
+**Jira 工单获得共识的要求：**
- - Formal requirements
- - The *Title* describes the problem concisely.
- - The *Description* gives all the details needed to understand the problem or feature request.
- - The *Component* field is set: Many committers and contributors only focus on certain subsystems of Flink. Setting the appropriate component is important for getting their attention.
- - There is **agreement** that the ticket solves a valid problem, and that it is a **good fit** for Flink.
- The Flink community considers the following aspects:
- - Does the contribution alter the behavior of features or components in a way that it may break previous users’ programs and setups? If yes, there needs to be a discussion and agreement that this change is desirable.
- - Does the contribution conceptually fit well into Flink? Is it too much of a special case such that it makes things more complicated for the common case, or bloats the abstractions / APIs?
- - Does the feature fit well into Flink’s architecture? Will it scale and keep Flink flexible for the future, or will the feature restrict Flink in the future?
- - Is the feature a significant new addition (rather than an improvement to an existing part)? If yes, will the Flink community commit to maintaining this feature?
- - Does this feature align well with Flink's roadmap and currently ongoing efforts?
- - Does the feature produce added value for Flink users or developers? Or does it introduce the risk of regression without adding relevant user or developer benefit?
- - Could the contribution live in another repository, e.g., Apache Bahir or another external repository?
- - Is this a contribution just for the sake of getting a commit in an open source project (fixing typos, style changes merely for taste reasons)
- - There is **consensus** on how to solve the problem. This includes considerations such as
- - API and data backwards compatibility and migration strategies
- - Testing strategies
- - Impact on Flink's build time
- - Dependencies and their licenses
+ - 正式要求
+ - 描述问题的 *Title* 要简明扼要。
+ - 在 *Description* 中要提供了解问题或功能请求所需的所有详细信息。
+ - 要设置 *Component* 字段：许多 committers 和贡献者，只专注于 Flink 的某些子系统。设置适当的组件标签对于引起他们的注意很重要。
+ - 社区*一致同意*使用 tickets 是有效解决问题的方法，而且这**非常适合** Flink。
+ Flink 社区考虑了以下几个方面：
+ - 这种贡献是否会改变特性或组件的性能，从而破坏以前的用户程序和设置？如果是，那么就需要讨论并达成一致意见，证明这种改变是可取的。
+ - 这个贡献在概念上是否适合 Flink ？这是一个特殊情况，是因为它使简单问题变复杂，还是使 abstractions 或者 APIs 变得臃肿？
+ - 该功能是否适合 Flink 的架构？它是否易扩展并保持 Flink 未来的灵活性，或者该功能将来会限制 Flink 吗？
+ - 该特性是一个重要的新增(而不是对现有部分的改进)吗？如果是，Flink 社区会承诺维护这个特性吗？
+ - 这个特性是否与 Flink 的路线图以及当前正在进行的工作内容一致？
+ - 该特性是否为 Flink 用户或开发人员带来了附加价值？或者它引入了回归的风险而没有给相关的用户或开发人员带来好处？
+ - 该贡献是否存在于另一个存储库中，例如 Apache Bahir 或另一个外部存储库？
+ - 这仅仅是为了在开源项目中获得提交而做出的贡献吗（仅仅是为了获得贡献而贡献，才去修复拼写错误、改变代码风格）?
+ - 在如何解决这个问题上已有**共识**，包括以下需要考虑的因素
+ - API 、数据向后兼容性和迁移策略
+ - 测试策略
+ - 对 Flink 构建时间的影响
+ - 依赖关系及其许可证
-If a change is identified as a large or controversial change in the discussion on Jira, it might require a [Flink Improvement Proposal (FLIP)](https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals) or a discussion on the [dev mailing list]( {{ site.base }}/community.html#mailing-lists) to reach agreement and consensus.
+如果在 Jira 的讨论中发现改动是一个大的或有争议的变更，则可能需要有 [Flink 改动建议 ( FLIP )](https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals) 或在 [ dev 邮件列表]( {{ site.base }}/community.html#mailing-lists) 中讨论以达成一致意见。
-Contributors can expect to get a first reaction from a committer within a few days after opening the ticket. If a ticket doesn't get any attention, we recommend reaching out to the [developer mailing list]( {{ site.base }}/community.html#mailing-lists). Note that the Flink community sometimes does not have the capacity to accept all incoming contributions.
+贡献者可以在打开 ticket 后的几天内得到来自 committer 的第一回应。如果 ticket 没有得到任何关注，我们建议你联系 [dev 邮件列表]( {{ site.base }}/community.html#mailing-lists)。请注意，Flink 社区有时没有能力接受发来的所有贡献信息。
-Once all requirements for the ticket are met, a committer will assign somebody to the *`Assignee`* field of the ticket to work on it.
-Only committers have the permission to assign somebody.
+一旦满足了 ticket 的所有要求，committer 就会将某人*`分配`*给 ticket 的受理人以进行处理。
+只有 committer 才有权限分配 ticket 给某人。
-**Pull requests belonging to unassigned Jira tickets will not be reviewed or merged by the community**.
+**社区不会审查或合并属于未分配的 Jira ticket 的 pull request ！**
-<a name="implement"></a>
+<a name="实现"></a>
-### 2. Implement your change
+### 2. 实现你想改动的
-Once you've been assigned to a Jira issue, you may start to implement the required changes.
+一旦你被分配到了 Jira issue，你就可以开始去实现你想改动的内容。
-Here are some further points to keep in mind while implementing:
+以下是在实现时要注意的一些要点：
-- [Set up a Flink development environment](https://cwiki.apache.org/confluence/display/FLINK/Setting+up+a+Flink+development+environment)
-- Follow the [Code Style and Quality Guide]({{ site.base }}/contributing/code-style-and-quality.html) of Flink
-- Take any discussions and requirements from the Jira issue or design document into account.
-- Do not mix unrelated issues into one contribution.
+- [设置 Flink 的开发环境](https://cwiki.apache.org/confluence/display/FLINK/Setting+up+a+Flink+development+environment)
+- 遵循 Flink 的 [代码风格和质量指南]({{ site.base }}/contributing/code-style-and-quality.html)
+- 接受来自 Jira issue 或设计文档中的任何讨论和要求。
+- 不要将不相关的问题混合到一个贡献中。
-<a name="review"></a>
+<a name="审查"></a>
-### 3. Open a Pull Request
+### 3. 打开一个 Pull Request
-Considerations before opening a pull request:
+在打开 pull request 之前的注意事项：
- - Make sure that **`mvn clean verify`** is passing on your changes to ensure that all checks pass, the code builds and that all tests pass.
- - Execute the [End to End tests of Flink](https://github.com/apache/flink/tree/master/flink-end-to-end-tests#running-tests).
- - Make sure no unrelated or unnecessary reformatting changes are included.
- - Make sure your commit history adheres to the requirements.
- - Make sure your change has been rebased to the latest commits in your base branch.
- - Make sure the pull request refers to the respective Jira, and that each Jira issue is assigned to exactly one pull request (in case of multiple pull requests for one Jira; resolve that situation first)
+ - 确保 **`mvn clean verify`** 验证了你的更改，以确保所有检查都通过，代码构建并且所有测试都通过。
Review comment:
这里”确保 **`mvn clean verify`** 验证了你的更改“ 改成 ”确保 **`mvn clean verify`** 执行成功是“ 是不是会更好一些，这里本地执行这个，主要是保证 checkstyle 通过（这个验证代码格式），测试通过等
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org