yangjf2019 commented on a change in pull request #268: URL: https://github.com/apache/flink-web/pull/268#discussion_r426215097
########## File path: contributing/contribute-code.zh.md ########## @@ -136,91 +136,91 @@ Apache Flink is maintained, improved, and extended by code contributions of volu <a name="consensus"></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: +以下类型的更改需要向 Flink 的 d...@flink.apache.org 邮件列表发一封以 `[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 的某些子系统。设置适当的组件标签对于引起他们的注意很重要。 + - 社区*一致同意*使用工单是有效解决问题的方法，而且这**非常适合** Flink。 + Flink 社区考虑了以下几个方面： + - 这种贡献是否会改变特性或组件的性能，从而破坏以前的用户程序和设置？如果是，那么就需要讨论并达成一致意见，证明这种改变是可取的。 + - 这个贡献在概念上是否适合 Flink ？这是否是一种特殊场景？支持这种场景后会导致通用的场景变得更复杂，还是使整理抽象或者 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 }}/zh/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. +贡献者可以在打开工单后的几天内得到来自 Committer 的第一回应。如果工单没有得到任何关注，我们建议你联系 [dev 邮件列表]( {{ site.base }}/zh/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. +一旦满足了工单的所有要求，Committer 就会将工单*`分配`*给具体的人，这样你就可以开始写代码或者其他的贡献了。 Review comment: 已经修改。 ---------------------------------------------------------------- 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: us...@infra.apache.org
