content/zh/how-to-contribute/index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>How to Contribute on Apache Flink</title>
    <link>https://flink.apache.org/zh/how-to-contribute/</link>
    <description>Recent content in How to Contribute on Apache Flink</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>zh</language><atom:link href="https://flink.apache.org/zh/how-to-contribute/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>如何参与贡献</title>
      <link>https://flink.apache.org/zh/how-to-contribute/overview/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://flink.apache.org/zh/how-to-contribute/overview/</guid>
      <description> 如何参与贡献 # Apache Flink 是由一个开放友好的社区开发的。我们诚挚地欢迎每个人加入社区并为 Apache Flink 做出贡献。与社区交流和为 Flink 做贡献的方式包括：提问题、报告 bug、提议新特性、参与邮件列表的讨论、贡献代码或文档、改进网站和测试候选发布版本。
你想做什么？ # 为 Apache Flink 做贡献不仅仅包括贡献代码。下面列出来不同的贡献形式：
可以贡献的领域 详细说明 报告 Bug 要报告 Flink 的问题，请登录 Flink’s Jira，然后点击顶部红色的 Create 按钮。 请提供你遇到问题的详细信息，如果可以，请附上能够帮助我们复现问题的描述。 贡献代码 请阅读 </description>
    </item>
    
    <item>
      <title>贡献代码</title>
      <link>https://flink.apache.org/zh/how-to-contribute/contribute-code/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://flink.apache.org/zh/how-to-contribute/contribute-code/</guid>
      <description>贡献代码 # Apache Flink 是一个通过志愿者贡献的代码来维护、改进和扩展的项目。我们欢迎给 Flink 做贡献，但由于项目的规模大，以及为了保持高质量的代码库，我们要求贡献者遵循本文所阐述的贡献流程。
请随时提出任何问题！ 可以发送邮件到 dev mailing list，也可以对正在处理的 Jira issue 发表评论。
重要提示：在开始准备代码贡献之前，请仔细阅读本文档。请遵循如下所述的流程和指南，为 Apache Flink 做贡献并不是从创建 pull request 开始的。我们希望贡献者先和我们联系，共同讨论整体方案。如果没有与 Flink committers 达成共识，那么贡献可能需要大量返工或不予审核通过。
寻找可贡献的内容 # 如果你已经有好的想法可以贡献，可以直接参考下面的 &amp;ldquo;代码贡献步骤&amp;rdquo;。 如果你在寻找可贡献的内容，可以通过 Flink 的问题跟踪列表 浏览处于 open 状态且未被分配的 Jira 工单，然后根据 &amp;ldquo;代码贡献步骤&amp;rdquo; 中的描述来参与贡献。 如果你是一个刚刚加入到 Flink 项目中的新人，并希望了解 Flink 及其贡献步骤，可以浏览 适合新手的工单列表 。 这个列表中的工单都带有 starter 标记，适合新手参与。
代码贡献步骤 # 注意：最近（2019 年 6 月），代码贡献步骤有改动。社区决定将原来直接提交 pull request 的方式转移到 Jira 上，要求贡献者在创建 pull request 之前需在 Jira 上达成共识（通过分配到的工单来体现），以减轻 PR review 的压力。 1讨论 在 Jira 上创建工单或邮件列表讨论并达成共识</description>
    </item>
    
    <item>
      <title>审核 Pull Request</title>
      <link>https://flink.apache.org/zh/how-to-contribute/reviewing-prs/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://flink.apache.org/zh/how-to-contribute/reviewing-prs/</guid>
      <description>如何审核 Pull Request # 本指南适用于希望帮助审核代码的所有提交者和贡献者。感谢你的努力 - 良好的审核是开源项目中最重要也是最关键的部分之一。本文旨在协助社区开展代码审核工作，以达到下列目的：
让贡献者拥有良好的贡献体验。 将审核过程结构化，以涵盖所有需要检查的重要方面。 保持 Flink 代码的高质量。 避免贡献者和审核者花费大量时间完善代码却最终被拒绝提交的情况。 审核清单 # 每次审核都需要检查以下六个方面。 我们建议按照以下顺序进行检查，以避免在还没有就是否添加某项功能或需要改动达成共识之前或没有满足一些正式条件前，就花费时间进行详细的代码质量审核。
1. 贡献的描述是否清晰？ # 检查贡献是否有充分的描述以方便审核，不重要的更改和修复不需要很长的描述。如果实现方案完全是按照之前在 Jira 或 dev 邮件列表上讨论结论进行的话，只需要一个对讨论的简短的引用即可。 如果实现方案与之前达成一致的方案不同的话，关于实现的详细描述是需要的，以便 review 贡献时更深入地讨论。
任何改变功能或行为的 pull request 都需要描述这些改变的重点, 以便知道审核什么内容(并且不必钻研代码来了解更改的作用)。
如果在不查看代码的情况下能回答以下问题2、3、4，则该贡献得到了很好的描述。
2. 是否一致认为这一变更或者功能应该进入 Flink？ # 这个问题要直接在关联的 Jira issue 中回答。对于在达成一致前创建的 pull request 来说，需要先在 Jira 中寻求一致的意见。
对于 [hotfix] 类型的的 pull request，可以在 pull request 中寻求意见一致。
3. 贡献是否需要一些特定的 committer 的关注，这些 committer 有时间投入吗？ # 一些更改需要特定的 committer 的注意和批准。例如，对性能非常敏感或对分布式协调和容错有关键影响的部件中的更改，这需要一个对相应组件非常熟悉的 committer 的审核。
根据经验，当 pull request 描述中对模板里问题 “Does this pull request potentially affect one of the following parts” 的回答为 “yes” 时，需要特别注意。</description>
    </item>
    
    <item>
      <title>代码样式与质量指南</title>
      <link>https://flink.apache.org/zh/how-to-contribute/code-style-and-quality-preamble/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://flink.apache.org/zh/how-to-contribute/code-style-and-quality-preamble/</guid>
      <description>Apache Flink Code Style and Quality Guide # 序言 # Pull Requests &amp;amp; Changes # 常用编码指南 # Java 语言指南 # Scala 语言指南 # 组件指南 # 格式指南 # 这是对我们想要维护的代码和质量标准的一种尝试。
一次代码贡献(或者任何代码片段)可以从很多角度进行评价：一组评判标准是代码是否正确和高效。这需要正确且良好的解决逻辑或算法问题。
另一组评判标准是代码是否使用了简洁的设计和架构，是否通过概念分离实现了良好的架构，是否足够简单易懂并且明确假设。该评判标准需要良好的解决软件工程问题。一个好的解决方案需要代码是容易被测试的，可以被除了原作者之外的其他人维护的（因为打破之后再维护是非常困难的），同时还需要能够高效的迭代演进的。
不过第一组标准有相当客观的达成条件，相比之下要达到第二组评判标准更加困难，但是对于 Apache Flink 这样的开源项目来说却非常重要。为了能够吸引更多贡献者，为了的开源贡献能够更容易被开发者理解，同时也为了众多开发者同时开发时代码的健壮性，良好工程化的代码是至关重要的。1 对于良好的工程代码来说，更加容易保证代码的正确性和高效不会随着时间的推移受到影响
当然，本指南并不是一份如何写出良好的工程代码的全方位指导。有相当多的书籍尝试说明如何实现良好的代码。本指南只是作为最佳实践的检查清单，包括我们在开发 Flink 过程中遇到的模式，反模式和常见错误。
高质量的开源代码很大一部分是关于帮助 reviewer 理解和双重检查执行结果。所以，本指南的一个重要目的是关于如何为为 review 构建一个良好的 pull request
在早期，我们（Flink 社区）并没有一直对此给予足够的重视，导致 Flink 的一些组件更难进化和贡献。&amp;#160;&amp;#x21a9;&amp;#xfe0e;</description>
    </item>
    
    <item>
      <title>贡献文档</title>
      <link>https://flink.apache.org/zh/how-to-contribute/contribute-documentation/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://flink.apache.org/zh/how-to-contribute/contribute-documentation/</guid>
      <description>贡献文档 # 良好的文档对任何类型的软件都至关重要。这对于复杂的软件系统尤其如此，例如 Apache Flink 这样的分布式数据处理引擎。Apache Flink 社区旨在提供简明、精确和完整的文档，并欢迎任何改进 Apache Flink 文档的贡献。
获取文档资源 # Apache Flink 的文档和代码保存在相同的 git 仓库中。这样做是为了确保代码和文档可以轻松保持同步。
贡献文档的最简单方法是在 GitHub 上 Flink 的镜像仓库 页面，通过单击右上角的 fork 按钮讲 Flink 克隆到你自己的 GitHub 帐户中。如果你没有 GitHub 帐户，可以免费创建一个帐户。
接下来，将 fork 的代码克隆到本地计算机。
git clone https://github.com/&amp;lt;your-user-name&amp;gt;/flink.git 文档位于 Flink 代码库的 docs/ 子目录中。
在开始贡献文档之前… # …请确保已经有一个相对应的 Jira issue 存在了。我们要求所有文档更改都需要关联一个 Jira issue，除了一些微不足道的修复，如拼写错误。
同时，先阅读一下 文档样式指南 能够很好的帮助你写出易懂、连贯和全面的文档。
更新或扩展文档 # Flink 文档是用 Markdown 编写的。Markdown 是一种轻量级标记语言，可以通过工具转化成 HTML。
为了更新或扩展文档，你必须修改 Markdown (.md) 文件。请通过在预览模式下启动构建脚本来验证你的更改。
./build_docs.sh -p 该脚本会将 Markdown 文件编译成静态 HTML 页面并在本地启动一个 Web 服务器。在浏览器中打开 http://localhost:1313/ ，查看包含更改文档页面。当你修改并保存 Markdown 文件，然后刷新浏览器，修改过的文档将自动被重新编译和更新。</description>
    </item>
    
    <item>
      <title>文档样式指南</title>
      <link>https://flink.apache.org/zh/how-to-contribute/documentation-style-guide/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://flink.apache.org/zh/how-to-contribute/documentation-style-guide/</guid>
      <description>文档样式指南 # 本指南概述了在编辑以及贡献 Flink 文档中必要的样式原则。目的是在你的贡献之旅中可以投入更好的社区精力去改进和扩展既有文档，并使其更 易读、一致 和 全面。
语言 # Flink 同时维护了 英文 和 中文 两种文档，当你拓展或者更新文档时，需要在 pull request 中包含两种语言版本。如果你不熟悉中文，确保本次贡献补充了如下额外操作：
开一个翻译的 JIRA 请求单，并打上 chinese-translation 的标签； 在此请求单上添加到原始 JIRA 请求单的链接。 正在寻求有助于将现有文档翻译成中文的风格指南？请继续查阅 这个翻译规范。
语言风格 # 如下，你可以看到一些初步的原则，这些原则可以确保书写中的可读性和通俗易懂。如果想更深入、更细致的了解语言风格，也可以参考 通用准则。
语态和语气 # 使用主动语态。主动语态简洁，并让内容更具有吸引力。如果你在句子的动词后添加 by zombies 后仍然读的通，那么你用的就是被动语态。
主动语态 &#34;You can run this example in your IDE or on the command line.&#34;
被动语态
&#34;This example can be run in your IDE or on the command line (by zombies).&#34;</description>
    </item>
    
    <item>
      <title>贡献网站</title>
      <link>https://flink.apache.org/zh/how-to-contribute/improve-website/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://flink.apache.org/zh/how-to-contribute/improve-website/</guid>
      <description>改进网站 # Apache Flink 官网 介绍了 Apache Flink 及其社区。包括如下多种用途：
向来访者介绍 Apache Flink 及其特性。 鼓励来访者下载并使用 Flink。 鼓励来访者与社区进行互动。 我们欢迎任何改进官网的贡献。本文档包含了所有改进 Flink 官网所需要的信息。
获取官网源码 # Apache Flink 官网的源码托管在专用的 git 仓库中，并在 Github 中有一个镜像 https://github.com/apache/flink-web.
向官网贡献的最简单方式是通过单击右上角的 fork 按钮，将 Github 上官网的镜像 镜像到自己的仓库中。如果没有 Github 帐户，你可以免费创建一个。
接下来，把你镜像的仓库克隆到本地机器上。
git clone https://github.com/&amp;lt;your-user-name&amp;gt;/flink-web.git flink-web 目录包含了拷贝的仓库。官网的代码位于 asf-site 分支上。运行如下命令切换到 asf-site 分支
cd flink-web git checkout asf-site 目录结构和文件 # Flink 官网使用 Markdown 语言。Markdown 是一种轻量级标记语言，可以转换为 HTML。我们使用 Hugo 从 Markdown 生成静态 HTML 文件。
flink-web git 仓库中的文件和目录具有以下作用：</description>
    </item>
    
    <item>
      <title>Apache Flink 代码样式和质量指南 — 组件</title>
      <link>https://flink.apache.org/zh/how-to-contribute/code-style-and-quality-components/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://flink.apache.org/zh/how-to-contribute/code-style-and-quality-components/</guid>
      <description>Apache Flink 代码样式和质量指南 — 组件 # 序言 # Pull Requests &amp;amp; Changes # 常用编码指南 # Java 语言指南 # Scala 语言指南 # 组件指南 # 格式指南 # 组件特定指南 # 关于特定组件更改的附加指南。
配置更改 # 配置选项应该放在哪里？
‘flink-conf.yaml’: 所有属于可能要跨作业标准的执行行为的配置。可以将其想像成 Ops 的工作人员或为其他团队提供流处理平台的工作人员设置的参数。 ‘ExecutionConfig’: 执行期间算子需要特定于单个 Flink 应用程序的参数，典型的例子是水印间隔，序列化参数，对象重用。 ExecutionEnvironment (in code): 所有特定于单个 Flink 应用程序的东西，仅在构建程序/数据流时需要，在算子执行期间不需要。 如何命名配置键：
配置键名应该分层级。将配置视为嵌套对象（JSON 样式）
taskmanager: { jvm-exit-on-oom: true, network: { detailed-metrics: false, request-backoff: { initial: 100, max: 10000 }, memory: { fraction: 0.1, min: 64MB, max: 1GB, buffers-per-channel: 2, floating-buffers-per-gate: 16 } } } 因此生成的配置键应该：</description>
    </item>
    
    <item>
      <title>Code Style and Quality Guide — Common Rules</title>
      <link>https://flink.apache.org/zh/how-to-contribute/code-style-and-quality-common/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://flink.apache.org/zh/how-to-contribute/code-style-and-quality-common/</guid>
      <description>Code Style and Quality Guide — Common Rules # 序言 # Pull Requests &amp;amp; Changes # 常用编码指南 # Java 语言指南 # Scala 语言指南 # 组件指南 # 格式指南 # 1. Copyright # Each file must include the Apache license information as a header.
/* * Licensed to the Apache Software Foundation (ASF) under one * or more contributor license agreements. See the NOTICE file * distributed with this work for additional information * regarding copyright ownership.</description>
    </item>
    
    <item>
      <title>Code Style and Quality Guide — Formatting Guide</title>
      <link>https://flink.apache.org/zh/how-to-contribute/code-style-and-quality-formatting/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://flink.apache.org/zh/how-to-contribute/code-style-and-quality-formatting/</guid>
      <description>Code Style and Quality Guide — Formatting Guide # 序言 # Pull Requests &amp;amp; Changes # 常用编码指南 # Java 语言指南 # Scala 语言指南 # 组件指南 # 格式指南 # Java Code Formatting Style # We recommend to set up the IDE to automatically check the code style. Please follow the IDE Setup Guide to set up spotless and checkstyle .
License # Apache license headers. Make sure you have Apache License headers in your files.</description>
    </item>
    
    <item>
      <title>Code Style and Quality Guide — Java</title>
      <link>https://flink.apache.org/zh/how-to-contribute/code-style-and-quality-java/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://flink.apache.org/zh/how-to-contribute/code-style-and-quality-java/</guid>
      <description>Code Style and Quality Guide — Java # 序言 # Pull Requests &amp;amp; Changes # 常用编码指南 # Java 语言指南 # Scala 语言指南 # 组件指南 # 格式指南 # Java Language Features and Libraries # Preconditions and Log Statements # Never concatenate strings in the parameters Don’t: Preconditions.checkState(value &amp;lt;= threshold, &amp;quot;value must be below &amp;quot; + threshold) Don’t: LOG.debug(&amp;quot;value is &amp;quot; + value) Do: Preconditions.checkState(value &amp;lt;= threshold, &amp;quot;value must be below %s&amp;quot;, threshold) Do: LOG.</description>
    </item>
    
    <item>
      <title>Code Style and Quality Guide — Pull Requests &amp; Changes</title>
      <link>https://flink.apache.org/zh/how-to-contribute/code-style-and-quality-pull-requests/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://flink.apache.org/zh/how-to-contribute/code-style-and-quality-pull-requests/</guid>
      <description>Code Style and Quality Guide — Pull Requests &amp;amp; Changes # 序言 # Pull Requests &amp;amp; Changes # 常用编码指南 # Java 语言指南 # Scala 语言指南 # 组件指南 # 格式指南 # Rationale: We ask contributors to put in a little bit of extra effort to bring pull requests into a state that they can be more easily and more thoroughly reviewed. This helps the community in many ways:
Reviews are much faster and thus contributions get merged sooner.</description>
    </item>
    
    <item>
      <title>Code Style and Quality Guide — Scala</title>
      <link>https://flink.apache.org/zh/how-to-contribute/code-style-and-quality-scala/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://flink.apache.org/zh/how-to-contribute/code-style-and-quality-scala/</guid>
      <description>Code Style and Quality Guide — Scala # 序言 # Pull Requests &amp;amp; Changes # 常用编码指南 # Java 语言指南 # Scala 语言指南 # 组件指南 # 格式指南 # Scala 语言特性 # 在哪儿使用（和不使用） Scala # 对于 Scala 的 API 或者纯 Scala libraries，我们会选择使用 Scala。
在 core API 和 运行时的组件中，我们不使用 Scala。我们的目标是从这些组件中删除现有的 Scala 使用(代码和依赖项)。
⇒ 这并不是因为我们不喜欢 Scala，而是考虑到“用正确的工具做正确的事”的结果（见下文）。
对于 API，我们使用 Java 开发基础内容，并在上层使用 Scala。
这在传统上为 Java 和 Scala 提供了最佳的互通性 这意味着要致力于保持 Scala API 的更新 为什么我们不在 Core API 和 Runtime 中使用 Scala ？</description>
    </item>
    
  </channel>
</rss>