向 Foundation 贡献代码

术语

• 社区是对问题发表评论或打开拉取请求的任何人。其中包括你！
• Yetinaut 是拥有仓库写访问权限的 Foundation 的核心团队。

我们的一些杰出贡献者被誉为 Yetinauts。他们拥有代码库的直接写访问权限，并在基金会团队中负责框架的开发。你有兴趣在 Foundation 框架上留下自己的印记吗？无论你是只是提交错误，还是帮助我们编写新功能，都有很多方法可以为 Foundation 做出贡献。

修复你的讨厌之处

如果你想修复 Foundation 或任何 Foundation 的支持生态系统，有很多机会可以参与其中。为了方便起见，我们在 GitHub 上创建了一个“求助”标签。

找到我们确认为新贡献者合适的错误。

Foundation 有很多方面，这让拥有不同技能的人可以有机会参与其中。为了方便起见，我们在 Github 上创建了一个 求助 标签。我们使用标签来表明问题是错误、功能，以及每个问题的难易程度。

下表说明了我们在 Github 上使用的标签

标签类型	描述
	这些是现有组件的增强或新功能提案。新功能令人兴奋且有趣，可以提升 Foundation 的可用性或性能。
	入门的好去处的文档或基本 HTML/CSS 问题。
	你的技能正在提升，你准备更进一步。它们涉及 Sass 问题调试、添加或更改 Sass 变量，以及次要的 JS 错误修复。
	你可能在寻求挑战。这些问题非常适合能够成为英雄并推动挑战走向胜利的人。这可能涉及高级 Sass 修复或增强、Gulp 或 ZURB Stack 中的工作流更新，以及棘手的 JS 错误修复。

不要担心 - 如果你不确定如何解决具体问题，可以在问题上向我们咨询，我们会指导你。

找到一些事情来做

如果你有兴趣为 Foundation 做出贡献，而不仅仅是修复错误，这里有一系列我们希望看到的，以便为 Foundation for Sites 提供更广泛的覆盖范围，或使其更容易使用。

框架组件求助

• 类型学：垂直节奏
• 下钻：动态高度
• 标签页：深度链接
• 标签页：哈希支持
• 媒体查询：方向检查
• 固定：处理短页面
• 固定：定义开始固定时间
• 下拉菜单：精确调整
• 下拉菜单：垂直节奏
• 下拉菜单：防止自动调整大小
• 显示：后退按钮
• 交换：带宽检测

为 Foundation 生态系统做出贡献。

如果您编写或移植了软件包、插件、工具、叶曼生成器等，并且您认为其他人会从中受益，可以考虑将其发布到社区。如果您发布一个被许多人认为有价值的软件包，那么您可以获得来自互联网的大量好评。博客文章、学习资源、翻译和开源代码也同样受欢迎；您可以通过带@zurboundtion发推或在 Foundation 论坛上发帖获得反馈并分享您的工作。

愿望清单

如果您有兴趣除了修复 bug 之外还为 Foundation 做出贡献，我们列出了我们希望看到完成的事项，以扩大 Foundation for Sites 的覆盖范围，或者使其更加易于使用。

以下是我们非常希望在 Foundation 生态系统中看到的功能。此列表未按优先级排序。我们非常欢迎实施其中任何一项的贡献。

• UMD 支持
• 作为独立插件的 Joyride
• 作为独立插件的 Clearing
• ZURB 堆栈的 Yeoman 生成器
• Visual Studio 模板
• Foundation 的 Polymer 组件
• 基金会插件的 Angular 2 版本
• 来自 Bootstrap 的迁移指南

您可以在 GitHub 上找到Foundation for Sites 路线图。

始终欢迎提交请求

最常见的代码贡献是在 GitHub 上提交请求。您只需要一个 GitHub 帐户！如果您在项目中解决了某个问题，请与其他人分享！

如何提交请求

Foundation 是成千上万个——数万个——渐进改进的结果。如果没有众多贡献者的投入，它现在就不会成为这样的产品。虽然贡献可以改进任何开源产品，但有些更改比其他更改更有用。以下是成功为开源产品做出贡献或提出请求——并参与到一项伟大的事业中的方法。

我们通过 GitHub 接受对代码的调整和一般想法。此版本控制服务使我们可以跟踪对 Foundation（实际上是我们所做的任何项目）的更改，以防止许多开发人员意外覆盖彼此的工作。

什么是请求？

请求是对您对项目的一个副本（而不是原始副本）所做的更改。完成更改后，您可以提交更改以供项目的拥有者审核。如果您的更改获得批准，项目的拥有者会将其“合并”到项目中。

该批准过程至关重要。当您对 Git 存储库进行更改时，请求会告诉人们您在何时做了什么。请求远远不是“老大哥”的情形，它可以帮助每个人了解在给定的时间发生了什么，从而发现“啊哈，昨天的更改影响了我现在正在尝试做的事情。”

有大量的指南介绍了提出请求的技术方面的内容。接下来，我们将讨论什么是好的请求。

进行更改

以 Foundation 为例，提出请求的过程是

1. 从 GitHub 中 Fork 一个 Foundation 的副本。

“分叉”是指将项目复制到你的 GitHub 账户中的行为。系统将询问是哪个账户（如果你有多个账户）。对我们而言，个人账户就足够。如果你不小心将项目分叉到错误的账户，或者之后想要删除分叉，请不要担心。删除分叉不会给原始项目造成损害。

你将需要一个 Foundation 的分叉副本
• Foundation for Sites
• Foundation for Emails

2. 克隆分叉

这是一种“将副本下载到你的电脑”的高级说法。尽管你可以直接在 GitHub 中对文件进行更改，但更经常的做法是使用你最喜欢的代码编辑器进行更改。

3. 对克隆副本进行更改。

我们建议每次提交只进行一次更改，即每个更改进行一次描述性总结。我们稍后再讨论此事。

最好为你的更改或修复创建分支。每个问题或功能使用一个分支。提交你的更改，将它们推回到仓库以供审核。（有关设置 Git 的更多信息，请前往官方指南。)

增加机会：优秀的 PR 具备哪些要素

当向项目提交拉取请求时，它应完善详尽，而不应过于夸张。你需要描述你的意图并描述你的代码更改。要做到这一点并不总是容易的。

标题很重要。

标题需要描述正在进行更新的组件以及正在改变什么。这是一个标题，所以在这里写小说是没有必要的。关键是，它应该足够描述性，能让阅读标题的人员对正在发生的事情有一个表层了解。

好的	“垂直居中左右下拉箭头”
好的	“将按钮更改为打开新模态窗口，使用户留在同一页面。”
好的	“让标签的活动类名可配置。”
好的	“添加 (flex-)grid-row 大小修饰器”
不太好	“focus 状态和输入转换”
不太好	“链接描述。”
不太好	“#8409 的修复”

引用开放中的问题

如果存在直接与你正在提交的拉取请求关联的开放问题，则你应该引用它。这可以在标题或拉取请求的描述中完成。它有助于明确你正在解决的目的或用例，并将加快接受速度。

问题有分配给它们的编号。如果你粘贴相关问题的链接或编号，GitHub 将将这两者链接在一起。这不仅能增强你的描述，还可以自动关闭你引用的问题并发布更新。

以下关键字将通过引用关闭拉取请求中的问题
• 关闭
• 关闭
• 已关闭
• 修复
• 修复
• 已修复
• 解决
• 解决
• 已解决

示例

如果可能，包括示例。

代码的一行胜过描述的十行。具体情况视而定。

描述如何重现问题。

能够分解问题并测试解决方案对于在不使问题恶化的情况下修复问题至关重要。

说明问题存在的位置。

对于 Foundation 来说，这意味着命名有问题的组件。

不要只用一个描述提交许多文件。

在单个拉取请求中难以解读几十个带更改的文件，并且难以描述它们。

每个请求都应适量而专注。最好将特定的更改拆分为多个拉取请求，而不是让一个大型请求涵盖许多不同的组件。这样，如果项目的拥有者必须撤销更改（一个称为“回滚”的过程），他们不必完全抹掉您所做的每个更改。

有用的 PR 示例

以下是我们仓库中显示如何解决并关闭问题的一些问题

• 添加静态网格槽 #8508
• 修复重复 for 循环
• 修复：撤销使用折叠的 flex 网格嵌套行的边距
• 清理滑块逻辑并修复顶部末端错误
• v6.2.2 修复对单选按钮进行的遵守检查（如果只要求一个单选按钮）

编码标准

遵循我们编码标准的 PR 才是好的 PR。我们希望代码库使用一致的命名、类结构和语法。

您可以在我们的 GitHub 上的编码标准仓库 中找到 Foundation 的编码标准。

我在提交拉取请求时会发生什么？

真棒！简单来说，当您向 Foundation 提交 PR 时，团队成员将审查更改，如果更改有效，则将其合并到主分支中。

合并拉取请求需要进行测试。Foundation 核心团队成员或 Yetinaut 将测试组件，以确保拉取请求解决了问题并确保没有退化。这就是描述重现错误的步骤至关重要的原因。

帮助拉取请求更快合并的一种方法是帮助测试它们。特别是如果您的项目面临相同的挑战，那么查看拉取请求以确认它解决了问题将极大有助于合并拉取请求。

Foundation 核心团队成员或 Yetinaut 可能会提出问题、提供反馈或拒绝拉取请求并注明理由。Foundation 非常欢迎拉取请求，因此您可能会看到获得修改拉取请求的建议或指导，以便准备好合并拉取请求。

您的拉取请求合并后，GitHub 会通知您。恭喜，您刚刚帮助了数千人并为开源做出了贡献！我们会确保大喊一声，因为您很了不起！

分支很重要：了解 Foundation 的项目结构。

Foundation 使用一个专门的工作流程来管理代码更新。这指示了拉取请求和代码更新应转到何处。它有助于确保在递增版本中的一处对更新的代码进行测试，同时为新功能提供了一个地方。

开发

这是 Foundation 的默认分支，也是修正错误的地方。这也是 GitHub 会“默认”针对 PR 的地方。对于每个次要版本，都将测试开发分支，然后将其合并到主分支。所有错误修复都应定向到开发分支。

主分支

部署（公开）代码更新的主分支。不影响 Foundation 代码的文档更新应指向主分支。

v6.3

这是 Foundation 的下一个主要版本。所有新功能、新组件和增强功能都应定向到下一个主要版本分支（目前为 Foundation for Sites 的 v6.3，以及 Emails 的 v2.3）

报告问题

发现已确认的错误？针对您对框架的任何问题提出问题。如果您的问题中缺少任何内容，例如其他内容、代码示例等，团队成员将在评论中要求提供更多信息。

将其记录在 GitHub 上，这样某人就有机会修复它。如果您在论坛上看到带有解决方案的问题，请评论并将其链接在一起。这肯定会帮助以后的成千上万的人。

您还可以从文档页面本身记录问题或修改文档。

• 编辑此页面：在 GitHub 中打开此页面，允许您编辑文档页面。当您提交更改时，它会在 Master 分支上创建一个 Pull 请求。
• 报告错误：带您前往 GitHub 中创建的问题。

支持请求通常更适合 Foundation 论坛，而 GitHub 更适合报告错误。如果您不确定您的问题是否为错误，别担心！在 GitHub 上发布您的问题，团队将为您提供帮助。希望每位参与者都遵守项目的 行为准则，所以请保持礼貌和尊重。