参与贡献

Provelopment Foundation 会因为使用者说出自己发现的问题而变得更好。参与不需要是开发者，也不需要许可，没有人要求您必须做什么。代码仓库是公开的，本页谈的不是「您应当做些什么」，而是「什么有帮助」。

大多数参与从遇到问题开始

有用的参与通常始于某人在自己的工作中撞上了什么：页面表现与预期不同；手册里写的配置没有那样生效；文档中的一句话可以有两种读法；某个步骤预设了您没有的权限。这些都是让项目变好的材料，而把它清楚地写下来本身就已经是贡献。

不必动手修。一份准确说明「期待什么、实际发生什么、跟着哪份文档操作」的报告，等于传达了修复的内容，因此常常比一个改动本身更有用。

没有哪一种是义务，也没有哪一种更高级。

使用 Foundation，并说出发现的问题
采用它、做一个真实站点，然后说明哪些顺利、哪些不顺利。来自正在运行站点的经验，是年轻项目能得到的最宝贵的东西。
报告缺陷
写下预期、实际发生的现象与复现步骤。附上所使用的 Foundation 版本、涉及的页面或配置，以及屏幕上出现的原始文字。配置写错与真正的缺陷，往往从报告形式就能区分。
提出改进建议
与其只给出想到的方案，不如说明您想解决的问题。负责该领域的人才能以适合项目的方式解决它。
改进文档
手册的读者是第一次接触 Foundation 的人。清楚的句子、遗漏的前置条件、修正过的示例、翻译，都会直接到达下一位读者。
提供技术工作
代码、测试、配置模式、随产品提供的示例。代码仓库中的文档说明了开发如何进行，以及提出变更之前需要包含什么。
帮助其他人
在公开场合回答其他使用者的问题，会帮助到之后有同样疑问的所有人。

这两件事常被混淆，却是不同的。您可以随时为自己的任何目的修改手中的副本，不需要征求许可。而某项改动是否被项目接纳，由维护者决定：他们会看它是否符合项目方向，以及是否还有余力承担。一个提案没有被接纳，并不会缩小您修改自己版本的自由。

大多数缺陷是使用者发现的。能被快速修复的报告有一些共同点——不是因为有什么格式要求，而是因为清楚的报告离修复更近。

写下预期与实际发生的现象。 两者的差别就是缺陷。「切换了语言，但切换器仍停留在英文」传达了信息，而「网站坏了」什么也没传达。

说明发生在哪里。 站点所使用的 Foundation 版本、涉及的页面或路由，如果只发生在某个语言，还要写明该语言。只在一个语言中出现的缺陷和所有语言都出现的缺陷，是两件不同的工作。

说明您改了什么。 是全新的 Foundation 项目，还是改动过的站点，这很关键。平台一侧的缺陷和建在其上的站点的缺陷是两件不同的工作，两者都值得报告。

原样引用信息。 报错文字本身常常是通往原因最短的路径，转述会丢掉恰恰关键的部分。

写下已经试过什么。 这能避免重复同样的工作，有时还能看出文档把人引向了错误的地方——那也是缺陷，是文档的缺陷。

如果您想提供的是技术工作而不是报告，项目对贡献的期望写在代码仓库里，值得在花时间之前先读。面向编码代理的工作规则、架构文档与校验手册一起说明了代码如何组织、变更应包含什么，以及校验关口到底证明了什么。其中还有一条项目规则：不能声称实现与测试实际验证之外的更多能力。

这些文档不是社区宪章，而是维护的纪律：它们说明如何让这份代码保持一致，同时也如实说明了资源——评审改动的维护者人数并不多。带有测试、问题清晰、又不夹带无关改动的提案，远比把理解负担丢给对方的提案容易被接受。

缺陷、建议与变更提案都记录在公开的代码仓库中。