贡献指南

• 1: 贡献者概述
• 2: 设计文档
• 3: 开发环境
• 4: 测试 Drycc
• 5: 提交拉取请求
• 6: 社区
• 7: 分流问题
• 8: 行为准则
• 9: Drycc 维护者

1 - 贡献者概述

提交 Bug 和增强功能

发现 bug？想要新功能？对维护者有请求？在适用的仓库中打开 GitHub issue，我们将开始对话。

我们的官方支持渠道是 Drycc #community Slack 频道。

不知道某个问题适用于哪个仓库？在 workflow 中打开 issue，或在 Drycc #community Slack 频道 中与维护者聊天，我们会确保将其放到正确的位置。

此外，请查看[故障排除][]文档以了解常见问题。

在打开新 issue 之前，搜索看看是否其他人已经报告了这个问题会很有帮助。您可以在这里搜索所有 Drycc 项目的 issue 列表。

编写文档

我们一直在寻求改进和扩展我们的文档。大多数文档位于 drycc/workflow 仓库中。只需 fork 项目，更新文档并向我们发送拉取请求。

贡献代码

我们一直在寻求帮助改进核心平台、其他工作负载、工具和测试覆盖率。有兴趣贡献代码？让我们在 Drycc #community Slack 频道 中聊天。请务必查看标记为 easy fix 或 help wanted 的 issue。

当您准备开始编写代码时，请查看设计文档并设置您的开发环境。

通过为任何 Drycc 项目做贡献，您同意其开发者证书起源 (DCO)。此文档由 Linux 内核社区创建，是一个简单的声明，即作为贡献者，您拥有合法权利做出贡献。

分流 Issue

如果您没有时间编码，可以考虑帮助分流。社区会感谢您通过花费一些时间来节省他们的时间。有关更多信息，请参见分流 Issue。

分享您的经验

在我们的用户邮件列表或实时在 Drycc #community Slack 频道中与社区互动，您可以随时与其他 Drycc Workflow 用户聊天。

2 - 设计文档

在提交将显著改变任何 Drycc 组件行为的拉取请求之前，例如新功能或主要重构，贡献者应该首先打开一个代表设计文档的问题。

目标

设计文档帮助确保项目贡献者：

• 在功能开发中尽早涉及利益相关者
• 确保代码更改实现原始动机和设计目标
• 为功能或更改建立明确的验收标准
• 强制执行测试驱动的设计方法和自动化测试覆盖

内容

设计文档问题应该命名为 Design Doc: <change description> 并包含以下部分：

目标

本节应简要描述提议的更改及其背后的动机。将编写测试以确保此设计目标由更改实现。

本节还应引用一个单独的 GitHub 问题，该问题跟踪功能或更改，通常分配给发布里程碑。

代码更改

本节应详细说明实现更改所需的代码更改，以及提议的实现。这应该尽可能详细，以帮助审阅者理解更改。

测试

所有更改都应由自动化测试覆盖，无论是单元测试还是集成测试（理想情况下两者都有）。本节应详细说明如何编写测试来验证更改是否实现设计目标并且不会引入任何回归。

如果更改无法通过自动化测试充分覆盖，则应重新考虑设计。如果受影响的代码部分根本没有测试覆盖，则应提交单独的问题以将自动化测试与该代码库部分集成。

此处描述的测试还形成了更改的验收标准，以便在完成后，维护者可以在确认测试通过 CI 后合并拉取请求。

批准

设计文档遵循与最终拉取请求相同的合并批准审查过程，维护者将特别注意确保任何更改的利益相关者都包含在设计文档的讨论和审查中。

一旦设计被接受，作者可以完成更改并提交拉取请求进行审查。拉取请求应关闭更改的设计文档以及跟踪问题或因更改而关闭的任何问题。

有关拉取请求和提交消息格式的更多信息，请参见提交拉取请求。

3 - 开发环境

在本指南中，我们将引导您完成设置适合对大多数 Drycc 组件进行黑客攻击的开发环境的过程。

我们努力使对 Drycc 组件进行黑客攻击变得简单。然而，必然有几个移动部件和一些设置要求。我们欢迎任何自动化或简化此过程的建议。

如果您刚刚接触 Drycc 代码库，请寻找带有 easy-fix 标签的 GitHub 问题。这些是更直接或低风险的问题，是熟悉 Drycc 的好方法。

先决条件

为了成功编译和测试 Drycc 二进制文件以及构建 Drycc 组件的容器镜像，需要以下内容：

• git
• Go 1.5 或更高版本，支持编译到 linux/amd64
• glide
• golint
• shellcheck
• Podman（在非 Linux 环境中，您还需要 [Podman Machine][machine]）

对于 drycc/controller，特别是，您还需要：

• Python 2.7 或更高版本（带有 pip）
• virtualenv（sudo pip install virtualenv）

在大多数情况下，您应该按照说明简单安装。不过有一些特殊情况。我们在下面介绍这些。

配置 Go

如果您的本地工作站不支持 linux/amd64 目标环境，您将不得不从源代码安装 Go，并支持交叉编译该环境。这是因为某些组件是在您的本地机器上构建的，然后注入到容器中。

Homebrew 用户可以安装带有交叉编译支持：

$ brew install go --with-cc-common

从源代码构建 Go 也很简单：

$ sudo su
$ curl -sSL https://golang.org/dl/go1.5.src.tar.gz | tar -v -C /usr/local -xz
$ cd /usr/local/go/src
$ # 首先为我们的默认平台编译 Go，然后添加交叉编译支持
$ ./make.bash --no-clean
$ GOOS=linux GOARCH=amd64 ./make.bash --no-clean

一旦您可以编译到 linux/amd64，您应该能够正常编译 Drycc 组件。

Fork 仓库

一旦满足先决条件，我们就可以开始处理 Drycc 组件。

从 Github 开始，fork 您想要贡献的 Drycc 项目，然后在本地克隆该 fork。由于 Drycc 主要用 Go 编写，最好的位置是在 $GOPATH/src/github.com/drycc/ 下。

$ mkdir -p  $GOPATH/src/github.com/drycc
$ cd $GOPATH/src/github.com/drycc
$ git clone git@github.com:<username>/<component>.git
$ cd <component>

如果您要向您 fork 的上游仓库发出拉取请求，我们建议配置 Git，以便您可以轻松地将代码变基到上游仓库的主分支。有各种策略可以做到这一点，但最常见的是添加一个 upstream 远程：

$ git remote add upstream https://github.com/drycc/<component>.git

为了简单起见，您可能希望将环境变量指向您的 Drycc 代码 - 包含一个或多个 Drycc 组件的目录：

$ export DRYCC=$GOPATH/src/github.com/drycc

在本文档的其余部分，$DRYCC 指的是该位置。

替代方案：使用 Pushurl Fork

许多 Drycc 贡献者更喜欢直接从 drycc/<component> 拉取，但推送到 <username>/<component>。如果该工作流程更适合您，您可以这样设置：

$ git clone git@github.com:drycc/<component>.git
$ cd drycc
$ git config remote.origin.pushurl git@github.com:<username>/<component>.git

在此设置中，获取和拉取代码将直接与上游仓库一起工作，而推送代码将向您的 fork 发送更改。这使得保持最新状态变得容易，同时进行更改然后发出拉取请求。

进行更改

设置好开发环境并 fork 和克隆了您想要处理的代码后，您可以开始进行更改。

测试更改

Drycc 组件每个都包含一套全面的自动化测试，主要用 Go 编写。请参阅 testing 以获取运行测试的说明。

部署更改

虽然编写和执行测试对于确保代码质量至关重要，但大多数贡献者还希望将更改部署到实时环境中，无论是使用这些更改还是进一步测试它们。本节的其余部分记录了在开发集群中运行官方发布的 Drycc 组件并用您的自定义替换其中任何一个的过程。

运行用于开发的 Kubernetes 集群

要在本地或其他地方运行 Kubernetes 集群以支持您的开发活动，请参考 Drycc 安装说明 here。

使用开发注册表

为了便于将包含您的更改的容器镜像部署到您的 Kubernetes 集群，您需要使用容器注册表。这是一个位置，您可以将自定义构建的镜像推送到那里，从那里您的 Kubernetes 集群可以检索相同的镜像。

如果您的开发集群在本地运行（例如在 Minikube 中），实现这一目标的最有效和经济的方法是在本地作为容器运行容器注册表。

为了促进这一点，大多数 Drycc 组件提供了一个 make 目标来创建这样的注册表：

$ make dev-registry

在 Linux 环境中，开始使用注册表：

export DRYCC_REGISTRY=<主机机器的 IP>:5000

在非 Linux 环境中：

export DRYCC_REGISTRY=<drycc 容器机器 VM 的 IP>:5000

如果您的开发集群在 Google Container Engine 等云提供商上运行，上述本地注册表将无法被您的 Kubernetes 节点访问。在这种情况下，[DockerHub][dh] 或 quay.io 等公共注册表就足够了。

例如，要使用 DockerHub：

$ export DRYCC_REGISTRY="registry.drycc.cc"
$ export IMAGE_PREFIX=<您的 DockerHub 用户名>

要使用 quay.io：

$ export DRYCC_REGISTRY=quay.io
$ export IMAGE_PREFIX=<您的 quay.io 用户名>

注意尾随斜杠的重要性。

开发/部署工作流程

有了功能正常的 Kubernetes 集群和安装在其上的官方发布的 Drycc 组件，通过用包含您的更改的自定义构建镜像替换官方发布的组件，可以促进任何您已更改的 Drycc 组件的部署和进一步测试。大多数 Drycc 组件包括 Makefiles，其中包含专门旨在以最小摩擦促进此工作流程的目标。

一般情况下，此工作流程如下所示：

1. 使用 git 更新源代码并提交您的更改
2. 使用 make build 构建新的容器镜像
3. 使用 make dev-release 生成 Kubernetes 清单
4. 使用 make deploy 使用更新的清单重新启动组件

这可以使用 deploy 目标缩短为一行：

$ make deploy

有用的命令

一旦您的自定义 Drycc 组件已部署，以下是一些有用的命令，允许您检查集群并在必要时进行故障排除：

查看所有 Drycc Pods

$ kubectl --namespace=drycc get pods

描述 Pod

这通常对故障排除处于待处理或崩溃状态的 pod 很有用：

$ kubectl --namespace=drycc describe -f <pod 名称>

尾随日志

$ kubectl --namespace=drycc logs -f <pod 名称>

Django Shell

特定于 drycc/controller

$ kubectl --namespace=drycc exec -it <pod 名称> -- python manage.py shell

有其他 Drycc 贡献者可能觉得有用的命令？给我们发 PR！

拉取请求

对您的更改满意？分享它们！

请阅读 Submitting a Pull Request。它包含了在提议对任何 Drycc 组件进行更改时应该做的事情的清单。

4 - 测试 Drycc

每个 Drycc 组件都包含自己的风格检查套件、[单元测试][] 和黑盒类型的 [功能测试][]。

[集成测试][] 验证 Drycc 组件作为一个系统的行为，并由 drycc/workflow-e2e 项目单独提供。

所有 Drycc 组件的 GitHub 拉取请求都由 Travis CI [持续集成][] 系统自动测试。贡献者在提议对 Drycc 代码库进行任何更改之前，应该在本地运行相同的测试。

设置环境

成功执行任何 Drycc 组件的单元测试和功能测试需要首先设置 开发环境。

运行测试

每个组件的风格检查、单元测试和功能测试都可以通过 make 目标执行：

要执行风格检查：

$ make test-style

要执行单元测试：

$ make test-unit

要执行功能测试：

$ make test-functional

要一次性执行风格检查、单元测试和功能测试：

$ make test

要执行集成测试，请参考 drycc/workflow-e2e 文档。

5 - 提交拉取请求

跨仓库提交

如果拉取请求是涉及其他 Workflow 仓库中的一个或多个额外提交的更大工作的部分，则这些提交可以在最后提交的 PR 中引用。下游 e2e 测试作业 将为测试运行器提供每个引用的提交（从提供的 PR issue 编号派生），以便它可以为要测试的生成的 Workflow chart 包含必要的容器镜像。

例如，考虑在 drycc/controller 和 drycc/workflow-e2e 中的配对提交。drycc/workflow-e2e 中第一个 PR 的提交主体将如下所示：

feat(foo_test): add e2e test for feature foo

[skip e2e] test for controller#42

为这个提交添加 [skip e2e] 会放弃 e2e 测试。除了最终 PR 之外的任何其他必需 PR 应该首先提交，以便它们的相应构建和镜像推送作业运行。

最后，应该使用所需的 PR 编号创建 drycc/controller 中的最终 PR，以 [Rr]equires <repoName>#<pullRequestNumber> 的形式列出，以供下游 e2e 运行使用。

feat(foo): add feature foo

Requires workflow-e2e#42

代码标准

Drycc 组件使用 Go 和 Python 实现。对于两种语言，我们同意 The Zen of Python，它强调简单胜过聪明。可读性很重要。

Go 代码应该始终使用默认设置通过 gofmt 运行。代码行最多可以长达 99 个字符。所有导出的函数都需要文档字符串和测试。第三方 go 包的使用应该最小化，但这样做时，此类依赖应该通过 glide 工具管理。

Python 代码应该始终遵守 PEP8，Python 代码风格指南，但例外是代码行最多可以长达 99 个字符。所有公共方法都需要文档字符串和测试，尽管 Drycc 使用的 flake8 工具不强制执行此项。

提交风格

我们遵循从 CoreOS 借来的提交消息约定，他们从 AngularJS 借来的。这是提交的示例：

feat(scripts/test-cluster): add a cluster test command

this uses tmux to setup a test cluster that you can easily kill and
start for debugging.

要使其更正式，它看起来像这样：

{type}({scope}): {subject}
<BLANK LINE>
{body}
<BLANK LINE>
{footer}

允许的 {types} 如下：

• feat -> 功能
• fix -> bug 修复
• docs -> 文档
• style -> 格式化
• ref -> 重构代码
• test -> 添加缺失的测试
• chore -> 维护

{scope} 可以是指定提交更改位置的任何内容。

{subject} 需要是祈使式、现在时动词：“change”，而不是 “changed” 也不是 “changes”。第一个字母不应大写，并且末尾没有点 (.)。

就像 {subject} 一样，消息 {body} 需要是现在时，包括更改的动机，以及与之前行为的对比。段落中的第一个字母必须大写。

所有破坏性更改需要在 {footer} 中提及，更改的描述、更改背后的理由以及所需的任何迁移说明。

提交消息的任何行都不能超过 72 个字符，主题行限制为 50 个字符。这允许消息在 GitHub 以及各种 git 工具中更容易阅读。

合并批准

任何代码更改 - 除了简单的拼写错误修复或单行文档更改 - 需要至少两个 Drycc 维护者 接受它。维护者使用 “LGTM1” 和 “LGTM2"（Looks Good To Me）标签标记拉取请求以表示接受。

在至少一个核心维护者以 LGTM 签字之前，不能合并任何拉取请求。另一个 LGTM 可以来自核心维护者或贡献维护者。

如果 PR 来自 Drycc 维护者，那么他或她应该是关闭它的人。这保持了提交流的清洁，并让维护者在决定是否合并更改之前重新审视 PR。

一个例外是当需要紧急恢复错误提交时。如果必要，仅恢复先前提交的 PR 可以不等待 LGTM 批准而合并。

Design Document

Before opening a pull request, ensure your change also references a design document if the contribution is substantial. For more information, see Design Documents.

Single Issue

It’s hard to reach agreement on the merit of a PR when it isn’t focused. When fixing an issue or implementing a new feature, resist the temptation to refactor nearby code or to fix that potential bug you noticed. Instead, open a separate issue or pull request. Keeping concerns separated allows pull requests to be tested, reviewed, and merged more quickly.

Squash and rebase the commit or commits in your pull request into logical units of work with git. Include tests and documentation changes in the same commit, so that a revert would remove all traces of the feature or fix.

Most pull requests will reference a GitHub issue. In the PR description - not in the commit itself - include a line such as “closes #1234”. The issue referenced will automatically be closed when your PR is merged.

Include Tests

If you significantly alter or add functionality to a component that impacts the broader Drycc Workflow PaaS, you should submit a complementary PR to modify or amend end-to-end integration tests. These integration tests can be found in the drycc/workflow-e2e repository.

See testing for more information.

Include Docs

Changes to any Drycc Workflow component that could affect a user’s experience also require a change or addition to the relevant documentation. For most Drycc components, this involves updating the component’s own documentation. In some cases where a component is tightly integrated into drycc/workflow, its documentation must also be updated.

Cross-repo commits

If a pull request is part of a larger piece of work involving one or more additional commits in other Workflow repositories, these commits can be referenced in the last PR to be submitted. The downstream e2e test job will then supply every referenced commit (derived from PR issue number supplied) to the test runner so it can source the necessary Container images for inclusion in the generated Workflow chart to be tested.

For example, consider paired commits in drycc/controller and drycc/workflow-e2e. The commit body for the first PR in drycc/workflow-e2e would look like:

feat(foo_test): add e2e test for feature foo

[skip e2e] test for controller#42

Adding [skip e2e] forgoes the e2e tests on this commit. This and any other required PRs aside from the final PR should be submitted first, so that their respective build and image push jobs run.

Lastly, the final PR in drycc/controller should be created with the required PR number(s) listed, in the form of [Rr]equires <repoName>#<pullRequestNumber>, for use by the downstream e2e run.

feat(foo): add feature foo

Requires workflow-e2e#42

Code Standards

Drycc components are implemented in Go and Python. For both languages, we agree with The Zen of Python, which emphasizes simple over clever. Readability counts.

Go code should always be run through gofmt on the default settings. Lines of code may be up to 99 characters long. Documentation strings and tests are required for all exported functions. Use of third-party go packages should be minimal, but when doing so, such dependencies should be managed via the glide tool.

Python code should always adhere to PEP8, the python code style guide, with the exception that lines of code may be up to 99 characters long. Docstrings and tests are required for all public methods, although the flake8 tool used by Drycc does not enforce this.

Commit Style

We follow a convention for commit messages borrowed from CoreOS, who borrowed theirs from AngularJS. This is an example of a commit:

feat(scripts/test-cluster): add a cluster test command

this uses tmux to setup a test cluster that you can easily kill and
start for debugging.

To make it more formal, it looks something like this:

{type}({scope}): {subject}
<BLANK LINE>
{body}
<BLANK LINE>
{footer}

The allowed {types} are as follows:

• feat -> feature
• fix -> bug fix
• docs -> documentation
• style -> formatting
• ref -> refactoring code
• test -> adding missing tests
• chore -> maintenance

The {scope} can be anything specifying the location(s) of the commit change(s).

The {subject} needs to be an imperative, present tense verb: “change”, not “changed” nor “changes”. The first letter should not be capitalized, and there is no dot (.) at the end.

Just like the {subject}, the message {body} needs to be in the present tense, and includes the motivation for the change, as well as a contrast with the previous behavior. The first letter in a paragraph must be capitalized.

All breaking changes need to be mentioned in the {footer} with the description of the change, the justification behind the change and any migration notes required.

Any line of the commit message cannot be longer than 72 characters, with the subject line limited to 50 characters. This allows the message to be easier to read on GitHub as well as in various git tools.

Merge Approval

Any code change - other than a simple typo fix or one-line documentation change - requires at least two Drycc maintainers to accept it. Maintainers tag pull requests with “LGTM1” and “LGTM2” (Looks Good To Me) labels to indicate acceptance.

No pull requests can be merged until at least one core maintainer signs off with an LGTM. The other LGTM can come from either a core maintainer or contributing maintainer.

If the PR is from a Drycc maintainer, then he or she should be the one to close it. This keeps the commit stream clean and gives the maintainer the benefit of revisiting the PR before deciding whether or not to merge the changes.

An exception to this is when an errant commit needs to be reverted urgently. If necessary, a PR that only reverts a previous commit can be merged without waiting for LGTM approval.

6 - 社区

Drycc 软件是完全开源的。因此，“Drycc 社区"由任何使用 Drycc 软件并参与其发展的人组成，无论是回答问题、发现错误、建议增强功能，还是编写文档或代码。

Drycc 开发通过众多项目仓库在 GitHub 上协调。任何人都可以查看任何 Drycc 组件的源代码，分叉它，进行改进，并创建拉取请求，将这些更改提供给 Drycc 社区。

Drycc 维护众多 Drycc 项目，因此决定最终出现在官方 GitHub 仓库中的内容。Drycc 依赖于社区的贡献；维护者不会忽略拉取请求或问题。

Drycc 使用永恒、高效且完全公平的系统，称为"终身仁慈独裁者”（BDFL）。Gabriel Monroy，Drycc 的创建者，是我们的 BDFL，对与 Drycc 相关的所有决定拥有最终决定权。

开源赏金

Drycc 项目支持赏金。我们相信开源赏金网站可以成为开发开源软件的有建设性工具。鼓励社区成员 a) 提供赏金和 b) 为有益于每个人的开源贡献获得赏金。然而，Drycc 维护者不会接受此项目的赏金，但很乐意帮助尝试赏金的社区成员。

7 - 分流问题

分流通过以下方式帮助确保问题快速解决：

• 精确传达问题的意图和目的。这是必要的，因为问题可能难以解释最终用户如何体验问题以及他们采取了什么行动。
• 在贡献者承诺解决问题的之前，为他们提供所需的信息。
• 通过防止重复问题来降低问题数量。
• 通过防止重复讨论来简化开发过程。

如果您没有时间编码，请考虑帮助分流。社区会感谢您通过花费一些时间来节省他们的时间。

确保问题包含基本信息

在对问题进行深入分流之前，请确保问题的作者提供了标准问题信息。这将帮助您对如何分类问题做出明智的建议。大多数问题中应包含的标准信息包括：

• 此问题影响的 Drycc 版本
• 如果这是 bug，可重现的案例
• 如果这是文档问题，则为页面 URL 或手册页面的名称

根据问题，您可能觉得并非所有这些信息都是必需的。请使用您的最佳判断。如果您无法使用问题的作者提供的内容来分流问题，请友好地向作者解释，他们必须提供上述信息来澄清问题。

如果作者提供了推荐的信息，但您仍然无法分流问题，请请求额外信息。请友好而礼貌地这样做，因为您在请求更多作者的时间。

如果作者在请求信息后一周内没有响应，请关闭问题，并附上友好的说明，说明作者可以在提供必要信息时请求重新打开问题。

分类问题

一个问题可以有以下多个标签：

问题类型

功能区域

• builder
• cache
• contrib and provisioning
• client
• controller
• database
• docs
• kubernetes
• registry
• router
• store (Ceph)
• tests

简单修复

“简单修复” 问题是新贡献者找到适合其经验水平问题的一种方式。这些问题通常适合对 Drycc（可能还有 Go）不熟悉的用户，他们希望在学习基础知识的同时提供帮助。

优先级问题

当附加到特定里程碑时，问题可以归属于以下标签之一，以指示其优先级程度。

就是这样。这应该是新贡献者或现有贡献者进来解决问题的所有必需信息。

8 - 行为准则

行为准则

Drycc 社区欢迎并鼓励每个人的参与。

无论您如何认同自己或他人如何看待您：我们欢迎您。只要与我们的社区建设性地互动，我们欢迎来自每个人的贡献。

Drycc 开发者社区继续增长，意见分歧和冲突不可避免。我们要求参与者按照这些原则行事：

1. 保持欢迎、友好和耐心。

2. 保持体贴。

您的工作将被其他人使用，反过来您也将依赖他人的工作。您做出的任何决定都会影响用户和同事，在做决定时应该考虑到这些后果。请记住，我们是一个全球性的社区，所以您可能不是用别人的母语进行沟通。

3. 保持尊重。

我们并非总是意见一致，但分歧不是不良行为和粗鲁举止的借口。我们可能偶尔会感到沮丧，但我们不能让这种沮丧变成人身攻击。重要的是要记住，一个让人们感到不舒服或受到威胁的社区不是一个富有成效的社区。

4. 谨慎选择您的措辞。

对他人友善。不要侮辱或贬低其他参与者。专业行事。请记住，骚扰以及性别歧视、种族歧视或排他性玩笑在社区中永远不合适。

（感谢 Debian 和 Django 社区的文本和灵感。）

9 - Drycc 维护者

什么是维护者？

（毫不掩饰地从 Podman 项目窃取而来）

有不同类型的维护者，具有不同的职责，但所有维护者有 3 个共同点：

1. 他们对项目的成功承担共同责任。
2. 他们对改进项目进行了长期、反复的时间投资。
3. 他们将时间花在需要做的事情上，不一定是他们最感兴趣或最有趣的事情。

维护者往往被低估，因为他们的工作更难被欣赏。欣赏一个真正酷炫和技术先进的特性很容易。欣赏 bug 的缺失、稳定性的缓慢但稳步改进，或发布过程的可靠性则更难。但这些东西将一个好的项目与一个伟大的项目区分开来。

Drycc 维护者

Drycc 除了我们亲爱的终身仁慈独裁者外，还有两个维护者群体。

BDFL

Drycc 遵循永恒、高效且完全不公平的系统，称为终身仁慈独裁者。

Gabriel Monroy (@gabrtv)，作为 Drycc 项目的创建者，担任我们项目的 BDFL。虽然日常项目管理由维护者执行，但 Gabriel 作为任何争议的最终仲裁者，并对项目方向有最终决定权。

核心维护者

核心维护者对 Drycc 的所有领域都具有异常丰富的知识。有些维护者全职在 Drycc 上工作，尽管这不是要求。

核心维护者的职责包括：

• 对 GitHub 问题进行分类和响应，并审查拉取请求
• 帮助塑造 Drycc 路线图并领导实现路线图里程碑的努力
• 积极参与功能开发和 bug 修复
• 在 Drycc #community Slack 频道 中回答问题并帮助用户

当前核心维护者的列表可以在这里看到。

在至少一个核心维护者以 LGTM 签字之前，不能合并任何拉取请求。另一个 LGTM 可以来自核心维护者或贡献维护者。

贡献维护者

贡献维护者对 Drycc 的某些但不一定是所有领域具有异常丰富的知识，并且通常由于特定领域知识而被选中，这些知识补充了项目（但持续贡献项目的意愿是最重要的！）。通常，核心维护者会要求贡献维护者在他们知识渊博的问题、拉取请求或对话中发表意见。

贡献维护者的职责与核心维护者非常相似，但它们限于贡献维护者知识渊博的 Drycc 项目领域。

贡献维护者在实践中被定义为那些对 Drycc 仓库具有写访问权限的人。所有维护者都可以审查拉取请求并根据需要添加 LGTM 标签。

成为维护者

Drycc 项目如果没有其社区就不会是今天的样子。项目的许多社区成员体现了维护者的精神，并为项目做出了重大贡献。

贡献维护者群体部分是为了让对项目持续成功感兴趣的杰出社区成员有机会与核心维护者一起指导 Drycc 的未来而创建的。

通常，潜在的贡献维护者由 Drycc 核心维护者基于以下标准部分选择：

• 在一段时间内（通常是几个月）对项目的持续贡献
• 愿意在 GitHub 和 Drycc #community Slack 频道 上帮助 Drycc 用户
• 友好的态度 :)

Drycc 核心维护者必须一致同意，才能邀请社区成员加入作为贡献维护者，尽管在许多情况下，候选人已经在贡献维护者的能力范围内行事一段时间，并已在问题、拉取请求等方面被咨询。